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REMARKS 

This response is in reply to the Office Action mailed 03 December 2004. The 
specification is objected to. Claims 1-21 are pending and are presently rejected. 
Applicants traverse the rejections without amending the claims. 

Objections to the Specification 

The Abstract is objected to and has been amended. Serial numbers of related 
applications have been supplied. 

Compact Disc Submission 

The description portion of this application contains computer program listings of 
more than 300 lines. Accordingly, the computer program listings appearing in the 
specification on pages 14-19, 20-24 and 24-35 have been deleted and such listing is on 
compact disc in compliance with 37 CFR 1 .96(c). 

Rejection Under 35 U.S.C. § 102(b) of Claims 1-21 

The Examiner rejects claims 1-21 under 35 U.S.C. § 102(b) as anticipated by 
Ogbuji, "Validating XML with Schematron" (2000). 

Claim 1 

Claim 1 includes the limitations: 

generating a second self-describing, structured document including, for any 
detected errors, 

at least one error identifier; and 

a path specification identifying a node within the primary document 
corresponding to the detected error; 

applying a declarative transformation to the first and second documents, 
producing a user interface character string, including a plurality of 

path specifications for nodes in the first document; and 

values for nodes in the first document; and 

at least one error message corresponding to the at least one error 
identifier; 
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These limitations are not found in Ogbuji. 

The code sample 2 on page for directly applies XSLT to detect an error and 
report the simple string "Invalid XML". This does not meet the detailed claim elements. 
The third paragraph on page 6 identifies language elements of Schematron, but does 
not teach how they are used and does not teach or suggest the claimed method steps. 
The specification of this application identifies weaknesses of Schematron and describes 
how these inventors have improved upon Schematron. Therefore, claim 1 should be 
allowable over Ogbuji. 
Claim 2 

Claim 2 should be allowable for at least the same reasons as claim 1 , from which 
it depends. 
Claim 3 

Claim 3 adds the limitations: 

further including validating the first document against a set of business 
processing rules and generating a third self-describing, structured document, 
wherein the declarative transformation is further applied to the third 
document 

These limitations are not found in Ogbuji, which does not teach or suggest the claimed 
method steps. Therefore, claim 3 should be allowable over Ogbuji. 
Claims 4-1 1 

Claims 4-11 should be allowable for at least the same reasons as claim 1 , from 
which they depend. 
Claim 12 

Claim 12 includes the limitations: 

validating the first document against a set of business processing rules 
applicable to the document type and an intended recipient of the first 
document; 

generating a second self-describing, structured document including, for 
any detected errors, 

at least one error identifier; and 

a path specification identifying a node within the primary document 
corresponding to the detected error; 

applying a declarative transformation to the first and second documents, 
producing a user interface character string, including a plurality of 
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path specifications for nodes in the first document; and 

values for nodes in the first document; and 

at least one error message corresponding to the at least one error 
identifier; 

These limitations are not found in Ogbuji, as explained above re claim 1 . Moreover, 
there are additional limitations in claim 12, not found in claim 1, which further distinguish 
over Ogbuji. Therefore, claim 12 should be allowable over Ogbuji. 
Claims 13-21 

Claims 13-21 parallel claims 2-11 above and should be allowable over Ogbuji for 
the reasons given above. 

Applicants respectfully submit that claims 1-21 should be allowable over Ogbuji. 

CONCLUSION 

Applicants respectfully submit that the specification and pending claims are now 
in condition for allowance and thereby solicit acceptance of the claims, in light of these 
amendments. 

The undersigned can ordinarily be reached at his office at (650) 712-0340 from 
8:30 to 5:30 PST, M-F and can be reached at his cell phone (415) 902-6112 most other 
times. 

The Commissioner is hereby authorized to charge any underpayment of fees, or 
credit any overpayment, to our Deposit Account No. 50-0869 (Attorney Docket No. JGR 
1008-1). 

Respectfully submitted, 

Dated: March 3, 2005 

Ernest J. Beffel, Jr., Reg. No. 43,489 

HAYNES BEFFEL & WOLFELD LLP 
P.O. Box 366 

Half Moon Bay, CA 94019 
(650) 712-0340 (telephone) 
(650) 712-0263 (facsimile) 
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METHOD AND APPARATUS FOR DECLARATIVE ERROR 

HANDLING AND PRESENTATION 

Inventors: Muljadi Sulistio 

Yang Wei 

5 Kelly Lane Schwarzhoff 

Yuan Din 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] The present application is related to commonly assigned, co-pending U.S. 
patent application No. 09/794,302, filed on February 27, 2001, entitled A METHOD 
10 AND APPARATUS FOR VIEWING ELECTRONIC COMMERCE-RELATED 
DOCUMENTS, by inventors Andrew Everett Davidson, Kelly Lane Schwarzhoff, 
Gunawan Herri, Changyi Zhu, Ari Krish, Muljadi Sulistio, and Sun Keun Lee, which 
is hereby incorporated by reference as if fully set forth. 

[0002] This application is further related to the following commonly assigned, co- 
15 pending applications filed on December 18, 2001, the same day as the present 

application: U.S. patent application No. 10/026,663, xCBL MAILBOX METHODS . 
AND DEVICES, by inventors Muljadi Sulistio, Yang Wei, Kelly Lane Schwarzhoff, 
Yuan Din, Sun Lee and Andy Yang; U.S. patent application No. 10/026,364, 
METHOD AND APPARATUS FOR DECLARATIVE UPDATING OF SELF- 
20 DESCRIBING, STRUCTURED DOCUMENTS, by inventors Muljadi Sulistio, Yang 
Wei, Kelly Lane Schwarzhoff and Yuan Din; and U.S. patent application No. 
10/026,682, METHOD AND APPARATUS FOR GENERIC SEARCH INTERFACE 
ACROSS DOCUMENT TYPES, by inventors Muljadi Sulistio, Yang Wei, Kelly 
Lane Schwarzhoff, Yuan Din, Sun Lee and Andy Yang. These applications filed on 
25 the same day are hereby incorporated by reference as if fully set forth. 

COPYRIGHT NOTICE 

[0003] A portion of the disclosure of this patent document contains material, 
which is subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent document or the patent disclosure is it 
30 appears in the Patent and Trademark Office patent file or records, but otherwise 
reserves all copyright rights whatsoever. 
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REFERENCE TO COMPUTER PROGRAM LISTING APPENDIX 

[0004] A computer program listing appendix comprising duplicate copies of a 
compact disk, named "XXX100X-1-CPLA" accompanies this application and is 
incorporated by reference. The computer program listing appendix includes the 
5 following files: 

Default-XSL 1 . txt 9 Kbytes on disk created 03 March 2005 

Default-XSL2.txt 7 Kbytes on disk created 03 March 2005 

JSP_CODE.txt 22 Kbytes on disk created 03 March 2005 

BACKGROUND OF THE INVENTION 

10 [0005] Electronic commerce between businesses has gained substantial 

momentum. Electronic marketplaces and XML or similar documents have begun to 
replace traditional EDI formats for commerce-related documents. Still, many 
businesses, particularly small and medium-sized businesses, have not adopted 
automated EDI or XML document processing. Whatever their size, many businesses 

15 face the prospect of an expedited implementation of EDI or XML document 

processing. It remains easier for large trading partners to generate XML or similar 
documents than it is for small to medium-sized businesses to adopt the technology 
needed to process them. In addition, a full scale conversion to EDI or XML 
transaction processing may involve far more documents than a business can 

20 practically convert in a workable time frame or on a reasonable budget. 

[0006] One problem with the implementation of EDI or XML transaction 
processing is the complexity and cost of procedural programming to process business 
documents. Procedural programming, otherwise known as hard coding, requires 
much effort to describe document transformations and manipulations in procedural 

25 terms, using programming languages such as Java and C++. This effort translates into 
time for implementation and cost of implementation. 

[0007] In some domains or problem spaces, declarative programming has been 
introduced. It is generally hoped that so-called declarative programming can make 
program customization accessible even to non-programmers. At the same time, it has 
30 been recognized that declarative programming is best when applied to a limited 

domain. Accordingly, declarative approaches are narrow and tailored, not generally 
applied. 
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[0008] Therefore, in the domain of exchanging self-defining, structured 
documents, it is desirable to develop declarative methods and components for 
simplifying the handling of documents. Declarative methods and components can 
improve interactions with users, particularly in the areas of producing documents, 
5 presenting error messages and searching for documents. 

SUMMARY OF THE INVENTION 

[0009] The present invention includes a method and device for declarative error 
handling and presentation. A further aspect of the present invention is extending 
XSLT's document() function to merge one or more error documents with a primary 
10 document for display. Additional aspects of the present invention are described in the 
claims, specification and drawings. 

BRIEF DESCRIPTION OF FIGURES 

[0010] Figure 1 is an overview of the user interface for an xCBL mailbox. 
[0011] Figure 2 is a sample screen display of a folder list, as part of a user 
15 interface. 

[0012] Figure 3 is a sample screen display for a list of documents within a folder, 
as part of a user interface. 

[0013] Figure 4 is a sample screen display for a indicating a reply document type. 
[0014] Figure 5 is the sample screen display for searching on a selected document 
20 type, as part of a user interface. 

[0015] Figure 6 is a block diagram of activities involving two trading partners 
communicating through a document exchange system. 

[0016] Figure 7 is an application flow providing additional detail of activities 
involving two trading partners communicating through a document exchange system. 
25 [0017] Figure 8 is a block diagram of a self-describing, structured document. 
[0018] Figure 9 illustrates participants in a marketplace. 
[0019] Figure 10 is a database schema for a data structure that may be used to 
practice aspects of the present invention. 

[0020] Figure 1 1 is one architecture for software components that handle generic 
30 documents. 

[0021] Figure 12 is a user interface and processing diagram, including validation 
of user created documents. 
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[0022] Figure 13 is a user interface for replying to a request for quote with a 
quote. 

[0023] Figure 14 is an action sequence for replying to a document. 
[0024] Figure 15 is a sequence diagram illustrating use of a servlet to control 
5 responses to a user action request. 

[0025] Figure 16 is a sequence diagram illustrating interaction between a servlet, 
interpreter and data structure engine, in response to data from a user. 
[0026] Figure 17 is a block diagram illustrating posting of data and some of the 
components involved in responding. 
10 [0027] Figure 18 is a simplified flow chart for a method of updating a self- 
describing, structured document. 

[0028] Figure 19 illustrates a protocol for updating a self-describing, structured 
document corresponding to one of a plurality of document schemas. 
[0029] Figure 20 is a flowchart overview of validation. 
15 [0030] Figure 21 is a flowchart overview of a method of searching a plurality of 
self-describing structure documents. 

[0031] Figure 22 a flowchart overview of preparing documents for searching. 
[0032] Figures 23-26 illustrate data tables used to prepare documents for 
searching. 

20 DETAILED DESCRIPTION 

[0033] The following detailed description is made with reference to the figures. 
Preferred and alternative embodiments are described to illustrate the present 
invention, not to limit its scope, which is defined by the claims. Those of ordinary 
skill in the art will recognize a variety of equivalent variations on the description that 
25 follows. 

[0034] Figure 1 depicts a user interface view of a system for handling generic 
business documents exchanged among trading partners. This illustrates an 
environment in which aspects of the present invention may be practiced. A user of a 
document exchange system uses a computer, terminal or other workstation to access a 
30 login screen 111. Standard login and authentication protocols can be followed. After 
a successful login, a user is presented with an initial mailbox screen 112. Figure 2 
depicts a sample initial screen. The user's choices from the initial screen may include 
folder management 121, document searching 122, listing of documents in the selected 
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folder 123 or selection of a particular document type of interest 124. Some of these 
options may be omitted or others may be added to a system. The folder management 
screen 121 provides typical functions for creating, deleting, renaming folders, etc. The 
document search screen 122 allows a user to select a document type and search on 
5 various criteria that are adapted to the selected document type. Figure 5 depicts a 
sample search screen. The list of documents in a folder screen 123 can be reached 
from either the initial screen or from a document search screen. It provides various 
information about documents in a folder, as shown in figure 3. The document type 
selection screen 124 can be implemented to allow a user to create a document from 
10 scratch. When a user selects a particular type of document to compose, the system 
can respond with a document compose screen 134 that includes the fields to be 
completed. 

[0035] From the list of documents in a folder screen, the user can export a 
document 131, read it 132, or use it as a basis for a new document 133, either by 
15 replying to or copying the base document. The document may be exported as an 
XML, PDF, CSV, HTML or other-formatted document. Standard or user-supplied 
export filters can be implemented. 

[0036] The processing of a user request to view a document can be understood by 
reference to the co-pending application for A Method and Apparatus for Viewing 

20 Electronic Commerce-Related Documents at pp. 5-52 and the figures cited therein. In 
general, a series of style sheets can be constructed for displaying documents. These 
style sheets may be written in XSLT, or another transformation language applicable to 
the data type of the documents. A series of style sheets may be written, from generic 
to highly customized. A rule selector can be used to select among the available style 

25 sheets based on criteria such as document type, marketplace identity, sender identity, 
receiver identity, portal identity or other selected criteria. A directory tree, database 
or other data structure can be used to access style sheets based upon the criteria used. 
[0037] A user can select among document types for a resulting reply document 
133. The available document types for a resulting reply document depend on the 

30 document type of the starting document type, for instance a starting document 

selected from a list of documents 123. Figure 4 is a sample screen from which a user 
selects a document type 442 for a resulting reply document. The reply document type 
can be the same as the starting type, for instance when a user is copying and reusing a 
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previous order as a template. The trading partner 443 may be identified by a full 
name, a short name and/or a unique identifier string. 

[0038] Figure 2 provides additional details of the folder management screen. The 
user is presented with standard screen functionality such as home, help and log off 
5 211. The current user and user organization are presented in the header 212. This is 
helpful for users who may belong to more than one organization. Options for 
accessing additional screens, such as the in box, composing a document, searching, 
addressee's and folders are presented. For figure 2, the active option is folders. 
Several columns of information about folders are provided, including folder name 

10 222, number of documents in a folder 223 and number of unread documents in the 
folder 224. Additional columns of information can be provided. 
[0039] Figure 3 provides additional details of the file list screen. General aspects 
of the screen follow the format of other screens, e.g. 21 1, 212, 221. The current 
folder being viewed and other folders available for view can be listed in the 

15 navigation box 331. The checkboxes 332 are provided for selecting individual 

documents to delete or to move to a folder. A column identifying the trading partners 
from whom documents originated 333 is provided. Date and time information and 
document types also are provided 334, 335. Icons for the document also can be 
provided 336. From the envelope icon, the user will know if the document has been 

20 read or not and also may know if it has been forwarded or replied to. From the export 
icon, the user can export the document. The same functionality can be provided for 
exporting a series of documents that have been checked. From the clip icon, the user 
can know if there are attachments associated with the document. The clip icon may 
allow direct access to a list of attachments or to the attachments themselves. 

25 [0040] The document type selection screen of figure 4 can lead to either a search 
or a reply action, depending on the context. In figure 4, a trading partner name and 
document type may be described in the banner 441, if they have been selected. 
Selection of a document type provides a context for either searching or replying. 
[0040A] Figure 5 depicts a sample search screen that includes many of the same 

30 features as other sample screens, e.g., 211, 212, 221, and 331. One or more field 

selection filters 512, 513 are supplied. The values accessible by the pull down menus 
of these filters are context sensitive to a selected document type, if the document type 
is selected by a filter 5 18 or has been selected by context in a prior screen. Only the 
field types that are valid for a particular document type appear in the pull down menu, 
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once a document type has been selected. One or more value specification fields 514 
also are provided. These value specification fields are context sensitive to the 
document fields. The user's entry can be checked for format and data type as the user 
enters the data. The combination of field selection filters and value specification 
5 fields, context sensitive to the document type selected, enables a generic interface for 
searching across different document types. In addition to generic field handling, 
additional filters can be provided to search by date 515, document status 516, trading 
partner 517 or other field. A variety of interfaces can be used to implement these 
filters, such as pull down menus, radio buttons, checkboxes, or blanks to fill in. A list 
10 of folders to search in 5 19 can be dynamically generated, to match the list of folders 
in the navigation box 221, 331. 

[0041] Figure 6 is a block diagram, at a very high level, depicting flow through 
activities related to exchange of documents between trading partners. A trading 
partner 601 using a connector sends a business document to a document router 606, 

15 which routes the document to a generic document handling service 609 within a 
service environment 608. The generic document handling service does some 
processing and, assuming no fatal error, stores the document inside database 607. 
Later, another trading partner 602 using a browser or other software adapted to 
communicate with the market site 603 accesses the Web server 604 running a 

20 document access servlet 605. The trading partner reads the document and, optionally, 
creates a response or uses the document as a basis for creating a new document. The 
second trading partner can access and create generic documents using a standard Web 
browser or other software. The servlet retrieves the starting document from the 
database 607. After a response or new document is created, the document can be sent 

25 to another trading partner 601. All of the functions of the market site 603 can be 
hosted on a single server. In some implementations, it is desirable to have separate 
servers for the router 606, the services 608, the database 607 and the Web servers 604. 
Additional servers or families of servers may be added for load balancing, high 
availability and/or security reasons. 

30 [0042] Figure 7 is a block diagram depicting an alternative system. Interacting 
with the system are an entity 701 which sends a document to the system and a user 
702 who interacts with the document stored by the system. The entity sends the 
document to a server 708 via router and communication channels that are not depicted 
in the figure. The document may reach the server 708 based on the addressee of the 
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document or a combination of addressee and document type, or it may be sent directly 
to a location specified by the sender. For instance, a global directory may be 
published that identifies locations to which participants in a marketplace desire for 
various types of documents to be sent. The locations may be specified in the form of 
5 market participant IDs or URLs. A market participant may have multiple IDs or 
URLs. 

[0043] A document being sent is typically a self-describing, structured document. 
XML documents are a common type of self-describing, structured documents. Fields 
within this document are self-describing, as the fields are tagged. A sample document 

10 having two different types of tagged fields is illustrated in figure 8. The document 
800 may have one or more parts 830, 840. For instance, the document may include a 
MIME header and an XML body. A MIME header may be compliant with RFC 822. 
The header 830 includes a plurality of tagged fields 831-833. The body 840 also 
includes a plurality of tagged fields 841-849. Alternatively, the document may have 

15 only one part or one type of tagged fields. These tagged fields may comply with a 
schema, such as an xCBL schema by Commerce One or a CXML schema by Areba. 
A scheme is characterized by tagged fields having types and super types. Types 
inherit properties from the super types on which they are based. Types are defined 
based on their super types and having additional properties. Other standards to which 

20 tagged fields may comply include Sox by Commerce One, ECX, the 0AGI standard 
of Open Applications.org, the BizTalk standard by Microsoft, the Rosetta net standard 
by Rosetta Net.org, and EDI X12 A32. 

[0044] Referring to figure 7, the entity which sent a document to the system 701 
may be an electronic trading partner or otherwise an electronic correspondent of the 

25 entity to which user 702 belongs. The relationship of trading partners or electronic 
correspondence is illustrated in figure 9. The trading partners participate in the 
trading network 900. This network may be hosted by a single entity or it may be a 
collaboration of networks hosted by distinct entities. The trading partners may both 
use the same host or they may use different hosts which route messages among 

30 themselves. Two trading partners 860, 880 are illustrated. Participants on behalf of 
the trading partners 861, 381 may be systems or human beings. Referring again to 
figure 7, the entity 701 which sends the document to the server 708 may be either a 
system or a human being. Purchasing systems are examples of entities which 
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generate self-describing, structured, tagged field documents and send them to 
systems. 

[0045] On server 708, one or more services 711-713 may be available. One 
service may receive the document 711. The same or another service 712 may 
5 persistently store the incoming document, for instance in a database 707. One or 
more databases may be used to store data useful for electronic commerce or other 
document exchange. A database may include a repository of schemas 741 for 
standard and entity-defined business documents, a repository of JavaBeans 742, C++ 
structures, Pascal records or scripts useful to electronic commerce, a document map 

10 repository 743 for translation of documents from one format to another (e.g., the 

xCBL format to an export format) and for transformation of documents from one type 
to another (e.g., from a request for quotation to a quotation.) The database may further 
include a report layout repository 744 and a presentation layout repository 745. The 
presentation layout repository may include declarative transformations for changing 

15 documents from a Sox document format to an HTML format, and back again. The 
transmission properties data describes the transport information needed to sent a 
business document to a recipient. For example, SSL security credentials can be stored 
as transmission properties. A trading partner directory is also useful. The trading 
partner directory may, as described above, identify URLs to which the sending entity 

20 701 transmits documents. The persistent storage for data 707, 741-47 may be on a 
single data storage unit or multiple units. Persistent document storage need not be 
part of a database. An indexed flat file would suffice to store XML-compliant 
documents. The services host 708 may also host an indexing service to index one or 
more of the tagged fields. Alternatively, a database system managing the persistent 

25 storage or other subsystem may index documents for retrieval. An incoming 

document may or may not be validated against schema from a schema repository 741, 
before it is persistently stored. A schema may be used to interpret the document. One 
or more JavaBeans or Scripps may be used to act on the document before it is stored. 
[0046] One schema for persistently stored documents is illustrated in figure 10. 

30 In this schema, a document and its header are captured in structure 1020. If this 

document is a copy or a reply based on an original document, the original document is 
stored in structure 1023. A copy or a reply document is associated with a special 
folder 1024. Document attachments are captured in structure 1040. Sets of valid 
document types and document statuses are maintained in structures 1010 and 1030, 
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respectively. The one-to-many connections between structures 1010, 1030 and 
structure 1020 indicate that only one document type and one document status are 
allowed per document. To support searching, searchable fields are listed in a data 
structure 1012, and may be assigned unique or non-unique alias names. Information 
5 regarding searchable fields is listed in a separate data structure 1022. Other data 
arrangements may equally well practice aspects of the present invention. 
[0047] Persistent storage of the incoming document may be accompanied by 
various processing steps. The original document, prior to normalizing, may be stored 
in a database. Envelope properties may be extracted from the envelope and 

10 normalized in a database or other storage. A predefined list of indexed fields, by 
document type, may be consulted and those fields indexed. Generic document 
properties, such as date and status, may be extracted from the envelope. The envelope 
itself may be separately stored. Attachments may be separately stored. Unneeded 
white space may be removed and name space abbreviations used to reduce storage 

15 requirements. 

[0048] Returning to figure 7, the service 713 may advise the user 702 of receipt of 
the document by messaging, posting any other practical means. One or more users 
may be given notice, based on the identity of the sending entity, the identity of the 
receiving entity, the document type or other characteristics of the document. One 

20 syntax for subscription by a user is subscription = sender ID.recipient ID.document 
type. To receive all Order documents from a particular sending entity, a user could 
subscribe as follows: subscription = SI 234.*. Order. This subscription would cause 
service 713 to notify user 702 of receipt of order type documents from sending entity 
SI 234. Security features of the system would, of course, restrict access appropriately. 

25 Notice may be given by messaging, such as e-mail or Lotus Notes messaging. A 
message may include a subject, such as, "five new documents received," header text 
generally stating that new documents have been received or that old documents 
remain to be viewed. The e-mail may further include body text providing the date, 
number and sending party's identities for documents received. The body text may 

30 further provide detail regarding individual documents received, such as the document 
type, sender identity and date or time of receipt. The user interface may identify the 
location for viewing the document, such as by a click through URL. Alternatively, 
notice may be given by posting at a location to which the user has access. A 
combination of notice formats may be used, such as posting followed by e-mail 
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follow-up in the user does not promptly access listed documents. E-mails based on 
the status of accessing a document or a post notice may be sent periodically and may 
include increasingly strong wording or additional addresses, based on the type and/or 
aging of the received document. 
5 [0049] A system 704 may be based upon a web server and a servlet container, for 
instance, compatible with JRun 3. A user interface application 721 may include a 
homepage 721, an in box 722, one or more services to read the document and/or its 
attachments 723, services for folder management 724, customized folders 725, 
searching for and listing documents. An additional service may provide access for 

10 downloading template documents 728. The web server may include Microsoft's 

Webserver software, a Java interpreter such as JRun 3 and a servlet container. A data 
storage interface may use the resources of a database. A first collection of services 
720 is illustrated as being coupled with a transformation engine 730. The 
transformation engine may include selection logic 732 to select the style sheet for 

15 transformation purposes and transformation logic 731 which applies a style sheet to a 
document. 

[0050] Figure 1 1 depicts a further alternative environment in which aspects of the 
present invention can be practiced, similar to the environments depicted in figures 6 
and 7. A web server 1111 takes HTTP requests and makes HTTP responses. A 

20 generic document handling facility takes advantage of the web server resources 

through a program interface. One useful API is Sun Microsystems Java servlet. The 
so-called servlet technology provides a simple, consistent mechanism for providing 
access to web server services. A servlet written in Java can provide a component- 
based, platform-independent method for building Web-based applications. A single 

25 servlet application may be integrated with a variety of web-enabled application 
servers such as BEA WebLogic Application Server, IBM WebSphere, iPlanet 
Application Server others. Complementary to servlet technology is Java Server Pages 
(JSP) support 1114. The JSP technology is an extension of servlet technology that 
supports authoring of HTML and XML pages. JSP facilitates mixing dynamic 

30 content with static templates. JSP supports encapsulation of logic to generate content 
dynamically. The dynamic content logic can be accessed from the template page. 
The servlet runner 1112 resident on the web server may be JRun or a similar Java 
environment. Alternatively, a different program interface to the web server may be 
used with a different programming language. The servlet runner supports the servlet 
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interface for access to the web server. The servlet runner supports the servlet 
controller 1113, invocation of JSP pages 1 1 14, and a variety of applications 1 121-26. 
Among these applications, the data access layer is an abstraction layer for access to 
the database 1151. The data access layer is present on each server or in each 
5 application environment that accesses the database 1 133, 1 144. XMLPres 1 122 is a 
style sheet engine that handles extended XSLT style sheets for transformation of 
XML into HTML. The rule selector 1 123, as described in the co-pending application, 
provides access to default or a customized rules and templates that match parameter 
such as document type and trading partner. The XML engine parses and processes 

10 XML documents. For XML, records can be parsed and processed using DOM, SAX 
or any other programming model. Folder management is provided 1 125. Software 
and resources for processing browser forms with embedded pass specifications are 
also provided 1 126, as described further below. E-mail notification 1131 may be 
structured with an e-mail module 1 132, a data access layer 1133, and e-mail 

15 management routines. The e-mail module will utilize routines of the data access layer 
and the e-mail management library. Sun Microsystems provides a library of e-mail 
management routines complementary to its servlet technology. The overall generic 
document exchange service 1 141 can be hosted within a services environment 1 142. 
The generic document exchange service 1 143 may include logic in resources for data 

20 access 1 144, XML transformation is 1 145 and XML searching and processing 1 146. 
Data accessed and utilized by these routines may be stored in multiple databases 
1 151, 1 152. A database of documents may be one component and market site data 
may be another, the market site data including a directory compliant with a 
lightweight directory access protocol. 

25 [0051] Figure 12 is a block diagram of a user interface and declarative data. This 
figure provides additional detail beyond the detail of figure 1 . The initial three 
screens, for displaying a document 132, selecting a document type 133, and 
composing a reply or new document 141 are the same as in figure 1. Figure 12 
depicts the use of declarative data for a mapping selector 1231, for data 

30 transformation mapping 1211, and for display transformation 1212 in conjunction 
with the document type selection screen 133. The mapping selector 1231 provides a 
list of document types that can be produced from a selected starting document is 
accessed and incorporated in the user interface. The types of resulting documents that 
can be produced may depend on the marketplace, trading partner and other factors, as 
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well as the document type of the starting document. From a starting document and 
selection of a document type for a resulting document, data transformation mapping 
121 1 is applied to generate a draft resulting document from the starting document. 
The transformation mapping should ensure that the resulting document is well 
5 formed, when the starting document is well formed. For XML to XML 

transformation, the declarative transformation mapping may take the form of an 
XSLT style sheet, potentially with extensions to XSLT. Other forms of declarative 
schema-to-schema mapping may also be used. Display transformation mapping 
utilizes declarative display format data 1 121 to transform the underlying data for use 

10 in the user interface, for instance, to transform XML to HTML they can be viewed by 
a browser. Following document type selection 133, application of declarative data 
from a mapping selector, data transformation mapping, and display transformation 
mapping is used to produce a document updates screen 141. In one embodiment, 
application of one or more declarative transformations to the starting document 

15 produces a user interface form. The user interface form includes a plurality of path 
specifications for fields corresponding to the document type of the resulting 
document, starting values based on the starting document for at least some of the 
fields in the resulting document, and values to be completed for other fields in the 
resulting document. Field labels also may be included, either as data or along with 

20 other page formatting information. Alternatively, all of the fields may be populated 
and none left to be completed. Some fields may be editable and others not editable. 
The path specifications may conveniently be implemented as HTML hidden fields or 
otherwise as non-displaying fields. They can be displayed, for instance, for 
debugging. XPath is one convention that can be used for path specifications to nodes 

25 or fields within an XML document. An alias for an XPath path specification also may 
be used, in conjunction with a lookup from the alias to the full path specification. 
Aliases can double as field labels. 

[0052] Sample excerpts of a document to display transformation 1212 for a main 
processing routine and display of header information with embedded path 
30 specifications are reflected in the file "Default_XSLl .txt" on the accompanying CD- 
ROM of source code. 

[0053] A draft resulting document also may be generated, in the process of 
producing the user form. This document may be produced according to a declarative 
transformation of a starting XML document into a draft resulting XML document. 
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The draft resulting document may include starting values from the starting document. 
It also may include default values for some fields and directions for completing other 
fields. The draft resulting document may be stored in memory according to a 
document-object-model (DOM) or another tree-based representation. Alternatively, 
5 the draft resulting document may be stored on disk or in memory in a form 

compatible with Simple API for XML (SAX or SAX2) or another event-based access 
model Or, an event-based API can be used to construct a tree, or traverse an in- 
memory tree. When a draft resulting document is generated, in addition to a form, the 
draft resulting document may be maintained in memory while the user works from the 

10 form and a document ID can be maintained with other state information for the draft 
resulting document. Alternatively, a document ID and related information can be 
transmitted with the user form, even in a stateless fashion, and the draft resulting 
document constructed after the user's updating of the form. A draft resulting 
document can be transformed with a display transformation to generate the user form. 

15 The display transformation may be generated with an XSLT stylesheet or another set 
of declarative data. 

[0054] Sample excerpts of a document to document transformation 1211 from a 
request for quotation to quotation follows, including portions of a main processing 
routine and a party copy routine, are reflected in the file "Default_XSL2.txt" on the 

20 accompanying CD-ROM of source code. 

[0055] The user acts upon the form 141. Fields are added, completed or changed. 
More than one iteration may be required, for instance, if a user adds a line item to a 
quotation. When the user is ready, the form is posted to the server for validation. 
One or more types of validation can be applied, such as field validation against a 

25 schema (e.g., for well-formedness and valid ranges) and business processing 

validation against a rule base. For instance, a SOX-compliant xCBL schema and a set 
of Schematron rules can be used for validation. In Figure 12, the flow branches from 
141 depending on whether field validation is error free. An error free field validation 
is displayed 1224 with a message. A document containing field errors results in 

30 generation of an error document that is merged for display with the original document 
by a declarative transformation 1212, thereby displaying validation errors in the same 
user interface as the document being edited 1213. The user's actions may be iterative, 
to correct one or more errors before repeating field validation. The user may be 
presented 1225 with further options of validating the document against business 
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processing rules applicable to one or more trading partners or of saving the document 
as a draft 1233. Alternatively, the multiple types of validations may be performed on 
the same document, without repeated user requests for validation. In one 
embodiment, business processing rules are applied by a Schematron engine 1232. 
5 [0056] Excerpts from a sample of a user form 141 that produced the sample 
screen in Figure 13 are reflected in the file "JSP_CODE.txt" on the accompanying 
CD-ROM of the source code. 

[0057] Figure 13 is a sample user interface screen. This screen corresponds to the 
HTML code above. Alternative embodiments may use a display language other than 

10 HTML or may use smart terminals or thin clients instead of being specifically adapted 
to browsers. In figure 13, a number of user controls are provided. A send control 
1301 allows a user to send a completed document. Preferably, the document is 
validated prior to the send control being functional. A save as draft control 1302 
allows the user to save the document without sending it or validating it. A validate 

15 control 1303 allows the user to invoke one or more levels of validation. Data entry 
validation may be supported for editable fields without invoking this validate control. 
For instance, numeric data may be required in the unit price field 1328 and the total 
price field 1331, even without invoking the validate control 1303. Controls for 
adding and removing line items 1304 are appropriate to a quote, request for quote or 

20 similar electronic commerce document. These controls may either invoke a procedure 
running within a browser, such as a JavaScript procedure, or may cause a client to 
contact a server for an updated screen. An add attachment control 1305 allows the 
user to add an attachment, which then is listed under attachments 1332. In this 
example, the fields of a quote can be grouped. The status of this example is draft 

25 1 3 1 1 . A reply to designee is identified 1312. The document type is a quote 1313. 
The quote header 1314 in this example includes a sequence number, which may be 
automatically generated by either the client or server, and a date field which may be 
automatically populated or manually entered. The issuer and recipient data 1315 is 
generated by a transformation of a request for quotation. The quote detail 1321 

30 includes several fields of various types. A status field populated from a pull down 
menu as provided 1322. An item number 1323 is given a starting value, which may 
be editable. Additional fields 1324-1327 copy into the quotation information from the 
request for quotation. The user completes the unit price 1328. A unit of measure is 
selected from a pull down menu 1329. This field could be given a starting value to 
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match the request for quotation. A total price field 1331 can be completed by the user 
or automatically calculated as an extension of the quantity and unit price. A quote 
summary field 1333 can be generated automatically or filled in by a user. Not visible 
in the sample screen, but included in the HTML code above are path specifications 
5 corresponding to fields of data that appear on the screen. Path specifications may be 
provided for all fields or only for editable fields. Also not visible are update status 
fields. The HTML code above provides a hidden update status field for at least the 
editable fields. This optional update status field can be used by either the client or the 
server to process and update more efficiently. The client can use an update status 
10 field to limit the information communicated to the server, in some embodiments. The 
server can use the update status field to avoid changing values already resident in 
memory, in some embodiments. 

[0058] Figure 14 is a sequence diagram for communications among components 
such as those depicted in the alternative embodiments of figures 6, 7 and 11. The 

15 browser 1401 is the component with which the user interacts. It may be a web 
browser, a thin client, a smart terminal or other equivalent hardware and software 
interface. The servlet 1402 runs on the server. The rule selector 1403 is a component 
for choosing the appropriate rules, forms etc. The transformation component applies 
a declarative transformation to a self-describing, structure document. For instance, an 

20 XSL style sheet can be applied to an XML document to generate a new XML 

document. Or, a JSP page or XSLT style sheet can be applied to an XML document 
to generate an HTML page for display. A variety of declarative transformations can 
be used. A database 1405 manages persistent storage. An XML engine 1406 
manipulates an XML document in memory. 

25 [0059] The sequence in figure 14 begins at the browser 1401, with a user viewing 
a request for quotation document 1411. The user requests generation of a reply 
document 1412. The servlet initiates mapping the document to a set of potential 
replies 1413. The servlet may receive from the browser a starting document type or it 
may receive a document ID for a self-describing, structured document and learn the 

30 document type from accessing the document. From a starting document type, the rule 
selector is invoked 1414 to determine the available reply types. The transformation 
engine generates an interface screen 1415, which the servlet returns to the browser 
1416. The user selects a reply type, for instance a quote 1417. The servlet transforms 
the starting document, in this example a request for quotation, into a draft resulting 
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document 1418, in this case a quote. In no particular order, a style sheet is retrieved 
1419 and applied to the quote to generate a user interface screen (implied), the quote 
is persisted by the database 1421 and, in some embodiments, the quote is loaded into 
an internal data structure for ease of manipulation 1421. This data structure may be a 
5 DOM tree. Once data for the user interface has been generated, it can be transmitted 
by the servlet to the browser 1422. The user updates fields and sends all or part of the 
data received from the servlet back 1423. The servlet may either have the draft quote 
in memory, it may retrieve the draft quote from the database 1424 and create a data 
structure in memory 1425 to be updated 1426, or it may create a quote from the data 

10 received back from the browser. In the embodiment illustrated here, the draft quote is 
retrieved from a database and updated 1426 with the fields that have been flagged as 
modified by the user. The updated data structure in memory is used to generate a 
self-describing, structured document 1427, which is persisted to the database 1428. 
Once updating has been accomplished, the update is communicated to the browser 

15 1429. Not shown in this sequence are the validation steps previously discussed. 

[0060] Figure 15 depicts an action command framework. In this framework, the 
servlet translates actions into one or more commands. This facilitates modification of 
process flow and reuse of sub process steps. A number of software components 1501- 
1507 are used to implement this framework. The sequence diagram depicts 

20 initialization of the object factory 1511. A request container is created 1512. The 
requested action from a user is created using the initialized object factory and request 
container 1513. The object factory acts to create the requested action 1514, consistent 
with appropriate selection of parameters, forms, etc. The servlet directs execution of 
the action 1515. A set of commands are created to carry out the action 1516. The 

25 object factory creates the appropriate commands 1517. The commands are executed 
1518, and an appropriate JSP page accessed 1519. 

[0061] Figure 16 depicts interaction among the servlet, the XPost interpreter and 
the XML engine when receiving a request from the client. A set of software 
components 1601-1616 are provided. Prior to the sequence illustrated in this figure, 
30 the servlet 1601 receives data including sets of update operators, path specifications 
and update values. In one embodiment, the servlet receives this data from a client 
browser via an HTTP post command in an HTML format. The servlet passes the data 
161 1 to an iterator 1602. The iterator builds a dictionary, table or other data structure 
in a form that the interpreter expects 1612. The servlet 1601 invokes 1613 interpreter 
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1603 to process the data structure. The interpreter exchanges messages 1614, 1615 
with access control to determine the security status of the requestor. Assuming that 
the security check passes, the interpreter instantiates 1616 the resources needed to 
process the data. Fields received from the user are unmasked 1617 from a user- 
5 friendly format to a canonical format used for internal processing. This un-masking is 
repeated as often as required 1618. With data in a canonical format, the XML engine 
1605 is invoked 1619 to update a document consistent with the data structure. The 
updated document is returned 1620, 1621. Some of the components involved in the 
sequence are depicted in the block diagram of figure 17. Updated HTML 1701 is 

10 posted via HTTP to the Web server 1702. The XPost interpreter 1703 acts upon 
XPost commands which may be stored in a hash table, dictionary or other data 
structure 1704. The XPost interpreter 1703 controls updating of an XML instance 
1712 in a database 1711, which manages persistent storage. 
[0062] Figure 18 is a simplified flow chart for a method of updating a self- 

15 describing, structured document. The character string 1801 is received. The 

character string may be encoded according to any of a variety of standards, such as 
UTF-8. The character string includes an update operator or other indication of the 
desired operation, a path specification identifying a node or location within a self- 
describing, structured document, at which the update operator is to be applied, and 

20 one or more update values. One update operator may apply to a plurality of path 

specifications and update values. Alternatively, the update operator may be received 
as part of the URL that invokes processing or it may be implied by the manner in 
which the update component is invoked. Update operators may include deleting an 
element, adding an element before an identified node as a sibling of the node, adding 

25 an element after the identified node is a sibling of the node, adding the element as a 
child of the identified node, or a combination of delete and add to accomplish a move 
or a replace. Other update operators can be supported. The past specification may be 
compliant with XPath or a subset of XPath. It is preferred to fully specify the path in 
absolute, instead of relative terms. Reference to identifying a node in the self- 

30 describing, structured document is not meant to imply that the document needs to be 
manipulated using the document object model or any other tree structured tool. The 
document can readily be manipulated with S AX-compliant tools or other event-driven 
tools. The character string is parsed 1802. A self-describing, structured document is 
accessed 1803. The document has a document type, which may be received or may 
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be obtained from the document itself. The document may be accessed from disk 1811 
or may already be resident in memory when the character string is received. XML 
documents are among those that can be considered self-describing, structured 
documents. A schema corresponding to the document type of the document is 
5 accessed 1804. The schema may be accessed from a database 1812, disk or memory. 
The schema is used for validating 1804 application of the update operator and update 
values at the node identified in the past specification. The schema may be SOX- 
compliant, XML schema-compliant, or RELAX-compliant. Other schemas may 
apply to XML or non-XML documents. Following successful validation, the 

10 document is updated 1805 with update values at the node specified in the past 

specification. In some embodiments, the character string will include a document ID 
or a binary document ID will be sent in addition to a character string. In other 
implementations, the document ID will be implied by prior state information, in 
which case the document may already be in memory. All or part of the document 

15 may be accessed via a data-object-model data structure in memory. Any of the 
embodiments may be used with the past specification that is compliant with any 
version of an XPath standard. Similarly, any of the embodiments may be used with a 
schema that is compliant with any version of a Sox standard. In some embodiments, 
an element set will be constructed, such as a set of fields for a line item in a purchase 

20 order. A set of elements associated with a single location or node may be assigned a 
shorthand or alias and accessed or specified using the shorthand or alias. When an 
alias is used for a set of elements, more than one update value may be associated with 
a single pass specification. In addition to validation against the schema, this process 
may further involve validation against a business processing rule set. The business 

25 processing rules may be selected according to the document type, trading partner, or 
other criteria. The business processing rules may be implemented by a set of 
Schematron declarations or may be implemented in procedural logic. 
[0063] Figure 19 illustrates a protocol for updating a self-describing, structured 
document corresponding to one of a plurality of document schemas. The entities 

30 represented in this diagram are a requestor 1901, a respondent 1902 and a source of 
declarative transformations 1903. The protocol begins with receiving of request 1911 
identifying a starting document and specifying a document type to be generated from 
the starting document. The identification of the starting document and the 
specification of the document type may be received in two separate messages, so that 
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the starting document is known from prior state information when the type of 
document is specified. The respondent, which may be a servlet running on a server, 
accesses one or more declarative transformations 1912, 1913 corresponding to the 
starting document and the specified document type. A rule selector may determine 
5 which declarative transformations are accessed. The system applies the declarative 
transformations to the starting document 1914, producing a plurality of path 
specifications for fields corresponding to the specified document type, starting values 
based on the starting document for at least some of the fields in some applications, 
fields to be completed by the user. The application of declarative transformations 

10 may produce a draft resulting document, a form, or both. In one embodiment, the 
system sends a form responsive to the request 1915 to the user, receives an updated 
form 1916, validates the update information 1917 and generates a final resulting 
document 1919. Validating the update information may involve one or more types of 
validation, such as validation against the schema and validation against business 

15 processing rules. 

[0064] Figure 20 is a flowchart overview of validation. A document 2001 is 
received 2002. Optionally, a set of declarative rules 201 1 for validation is accessed 
2003. The declarative rules may include schema level validation based on a Sox 
schema and business logic level validation using Schematron. If validation fails on 

20 the schema level, field validation errors may be displayed without proceeding to 
Schematron validation. Validation errors may be displayed adjacent to the node at 
which the error was detected. If validation fails on the Schematron level, error 
messages may be displayed at the top of the user interface or wherever appropriate, 
using the XSLT document () function. The default.xsl sample code set forth above 

25 includes logic for processing both Schematron and field validation errors. 

[0065] One or more errors in the primary document are detected 2004. A 
secondary self-describing, structured document 2012 including the detected errors is 
generated. For the detected errors, an error identifier and a path specification 
identifying a node within the primary document corresponding to one or more of the 

30 detected errors are generated. The primary 2001 and secondary 2012 documents are 
merged 2005 for display 2006. In one embodiment, the secondary document is an 
XML document. An enhanced version of the XSLT document () function is used to 
allow retrieval of the secondary document containing error text. The XMLPres 
component, which implements the XSLT functionality, is an enhanced version of 
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Apache Foundation's Xalan. This component takes into account various concepts 
such as name spaces in Sox documents and polymorphism. Extension of the 
document () function enables the loading of an external document to be specified by 
the invoker. 

5 [0066] Figure 21 is a flowchart overview of a method of searching a plurality of 
self-describing structure documents, the documents including document fields. A 
server 2101 provides a user Interface 2102. The user interface includes, in one or 
more screens, the document type selection filter and one or more document fields 
selection filters. These document field selection filters are context sensitive to the 

10 selected type of document, if a document type is selected. One or more value 

specification fields are supplied, to be filled in for the field selection filters. These 
value specification fields are context sensitive, so that field format errors, such as text 
characters in a numeric field, can be detected directly at the user interface, without 
return to the server. In addition, has non displaying fields, one or more path 

15 specifications corresponding to the document fields and the value specification fields 
are provided. The path specifications identifying nodes to be tested against the 
completed value specifications for a search. The server next receives data specifying 
a search 2104. This data typically comes from a user responding to the user interface. 
It includes the selected document type, completed value specifications and path 

20 specifications for the selected fields. Alternatively, aliases may be given for selected 
fields, which are expanded into path specifications by reference to a data structure 
2103. A search is conducted through a subset of self-describing, structured 
documents 2105, based on the completed value specifications and the corresponding 
path specifications. The subset includes documents of the selected document type. 

25 From the perspective of the user, the user interface displays a document type selection 
filter, one or more document field selection filters, which are context sensitive to a 
selected document type and one or more value specification fields, which are context 
sensitive to the document fields. Not displayed to the user, except perhaps a 
debugging mode, are path specifications corresponding to the document fields and the 

30 value specification fields. The path specifications identify nodes to be tested against 
completed value specifications when a search is conducted. The user selects a 
document type and one or more document fields appropriate to the document type. 
Value specifications are completed by the user. The user's selections are transmitted 
to a server which may then conduct a search. Recast as a device, the computer user 
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interface includes a document type selection filter, one or more document field 
selection filters coupled by context to a selected document type, one or more value 
specification fields, coupled by context to selected document fields, and, has non 
displaying fields, one or more path specifications corresponding to the document 
5 fields and to the value specification fields. 

[0067] A context-based search facility is user configurable. Database 
configuration interfaces may be used for specifying those fields to be indexed. The 
user interface can be configured to provide user-friendly names to be displayed 
corresponding to XPath or field element name representations. Configuring the user 

10 interface permits fields that have different names in different document types to begin 
a common, user-friendly name at the user interface. Figure 22 identifies components 
of context-based searching. Upon receiving a new document 221 1, the generic 
document handling service 2212 will scan its configurations 2201 to determine if 
2213 the document has been configured for content-based searching. If the document 

15 type is configured to be searched, the system identifies fields to be indexed. In one 
embodiment, it uses the XPath specification of the incoming document fields to locate 
the indexable fields. After indexing, a process is invoked to persist the data 2221. 
Persistent indexed data is stored 2222. Further processing proceeds. Database 
configuration is supported by various tables. 

20 [0068] Figure 23 depicts a document type list used for database search 
configuration. A list, table or other data structure may be used to capture all 
document types recognized by the generic document handling system, or at least by 
the indexing system. The type ID column 2301 contains an integer value for an 
automatically generated field ID. This unique field ID is used as a shorthand for the 

25 document type. The type column 2302 is the character string identifying the 

document type. For instance, "request for quotation" is a document type. The name 
space column 2303 identifies the name space to which this document type belongs. 
The name space may be a uniform resource name that fully qualifies a location at 
which a schema for the document can be found. Column 2304 is an extra column 

30 reserved for future use. The application-created column 2305 is an integer used to 
flag fields in which data is entered manually. This field should be left null if data is 
entered manually. 

[0069] Figure 24 depicts a field definition table that is populated with path 
specifications of elements that will be searched. The field definition column 2401 is 
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an automatically generated integer value, that is used as a shorthand for the field. The 
MPID column 2402 is a unique identifier for a particular trading partner for whom the 
past specification that follows is valid. The type ID column 2403 is an integer value 
mapped to the document's type ID 2301. Many fields can be mapped to a single 
5 document type. The name field 2404 is a path specification. In some embodiments, it 
is an XPath for an XML document. 

[0070] XPath provides a unique way to identify a field inside a XML document, 
but it may not be meaningful to an end user. As illustrated in Figure 25, an alias to 
the XPath may be used as an alternative to embedding the full XPath string with each 

10 field used in the interface. The alias may be displayed in the user interface as a field 
name. The generic document handling system will associate the alias with the full 
XPath string when user submits a request. The segment 2501 is an example of XPath 
and alias, segment 2502 is another example of multiple occurrence XPath and alias, 
segment 2503 is another example of different name space XPath and alias. 

15 [0071] Figure 26 is a table of searchable data extracted for indexing. The 
searchable field column 2601 identifies the field in which the data occurs. The 
document sequence field 2602 corresponds to the document in which the field was 
found. The field definition column 2603 corresponds to the field definition IDs in 
figure 24. The value column 2604 contains a searchable value. This value may be a 

20 single token or it may be the full contents of the field. A single token may, in some 
embodiments, include embedded blanks or other non-text characters. 
[0072] While the preceding examples are cast in primarily in terms of a method, 
devices and systems employing this method are easily understood. An electronically 
readable medium, such as a DVD, CD, memory module, magnetic disk or magnetic 

25 tape containing a program capable of practicing aspects the claimed method is one 
such device. A computer system comprising one or more servers and/or workstations 
having memory loaded with a program practicing the claimed method is another such 
device. 

[0073] While the present invention is disclosed by reference to the preferred 
30 embodiments and examples detailed above, it is understood that these examples are 
intended in an illustrative rather than in a limiting sense. It is contemplated that 
modifications and combinations will readily occur to those skilled in the art, which 
modifications and combinations will be within the spirit of the invention and the 
scope of the following claims. 
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CLAIMS 



1 1 . A method for error processing and reporting during validation of a business 

2 document in a client-server environment, the method including: 

3 accessing a first self-describing, structured document having a document type; 

4 validating the first document against a schema corresponding to the document 

5 type; 

6 generating a second self-describing, structured document including, for any 

7 detected errors, 

8 at least one error identifier; and 

9 * a path specification identifying a node within the primary document 

10 corresponding to the detected error; 

1 1 applying a declarative transformation to the first and second documents, 

12 producing a user interface character string, including a plurality of 

13 path specifications for nodes in the first document; and 

14 values for nodes in the first document; and 

15 at least one error message corresponding to the at least one error identifier; and 

16 transmitting the user interface character string. 

1 2. The method of claim 1 , wherein the schema is compliant with any version of 

2 a SOX standard. 

1 3. The method of claim 2, further including validating the first document against 

2 a set of business processing rules and generating a third self-describing, structured 

3 document, wherein the declarative transformation is further applied to the third 

4 document. 
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1 4. The method of claim 1, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 5. The method of claim 3, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 6. The method of claim 1, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 7. The method of claim 3, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 8. The method of claim 5, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 9. The method of claim 1, wherein the user interface character string is 

2 compliant with an XML standard. 

1 10. The method of claim 3, wherein the user interface character string is 

2 compliant with an XML standard. 

1 11. The method of claim 5, wherein the user interface character string is 

2 compliant with an XML standard. 

3 12. A method for error processing and reporting during validation of a business 

2 document in a client-server environment, the method including: 

3 accessing a first self-describing, structured document having a document type; 

4 validating the first document against a set of business processing rules applicable 

5 to the document type and an intended recipient of the first document; 

6 generating a second self-describing, structured document including, for any 

7 detected errors, 

8 at least one error identifier; and 

9 a path specification identifying a node within the primary document 
10 corresponding to the detected error; 
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1 1 applying a declarative transformation to the first and second documents, 

12 producing a user interface character string, including a plurality of 

13 path specifications for nodes in the first document; and 

14 values for nodes in the first document; and 

15 at least one error message corresponding to the at least one error identifier; and 

16 transmitting the user interface character string. 

1 13. The method of claim 12, wherein the business processing rules are 

2 Schematron-compliant. 

1 14. The method of claim 12, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 15. The method of claim 13, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 16. The method of claim 12, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 17. The method of claim 13, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 18. The method of claim 15, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 19. The method of claim 12, wherein the user interface character string is 

2 compliant with an XML standard. 

1 20. The method of claim 13, wherein the user interface character string is 

2 compliant with an XML standard. 

1 21. The method of claim 15, wherein the user interface character string is 

2 compliant with an XML standard. 
1 
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ABSTRACT 

The present invention includes a method and device for generic searching 
across document types. A further aspect of the present invention is indexing and 
searching XML documents using an HTML interface generated by a declarative 
transformation. 
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METHOD AND APPARATUS FOR DECLARATIVE ERROR 

HANDLING AND PRESENTATION 

Inventors: Muljadi Sulistio 

Yang Wei 

5 Kelly Lane Schwarzhoff 

Yuan Din 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] The present application is related to commonly assigned, co-pending U.S. 
patent application No. 09/794,302, filed on February 27, 2001, entitled A METHOD 

10 AND APPARATUS FOR VIEWING ELECTRONIC COMMERCE-RELATED 

DOCUMENTS (CMRC 1002 1) , by inventors Andrew Everett Davidson, Kelly Lane 
Schwarzhoff, Gunawan Herri, Changyi Zhu, Ari Krish, Muljadi Sulistio, and Sun 
Keun Lee, which is hereby incorporated by reference as if fully set forth. 
[0002] This application is further related to the following commonly assigned, co- 

15 pending applications filed on December 18, 2001, the same day as the present 

application: U.S. patent application No. 10/026,663 , xCBL MAILBOX 

METHODS AND DEVICES (CMRC 1010 1) , by inventors Muljadi Sulistio, Yang 
Wei, Kelly Lane Schwarzhoff, Yuan Din, Sun Lee and Andy Yang; U.S. patent 
application No. 10/026.364 , METHOD AND APPARATUS FOR 

20 DECLARATIVE UPDATING OF SELF-DESCRIBING, STRUCTURED 

DOCUMENTS (CMRC 1007 1) , by inventors Muljadi Sulistio, Yang Wei, Kelly 

Lane Schwarzhoff and Yuan Din; and U.S. patent application No. 10/026.682 , 

METHOD AND APPARATUS FOR GENERIC SEARCH INTERFACE ACROSS 
DOCUMENT TYPES (CMRC 1009 1) , by inventors Muljadi Sulistio, Yang Wei, 

25 Kelly Lane Schwarzhoff, Yuan Din, Sun Lee and Andy Yang. These applications 
filed on the same day are hereby incorporated by reference as if fully set forth. 

COPYRIGHT NOTICE 

[0003] A portion of the disclosure of this patent document contains material, 
which is subject to copyright protection. The copyright owner has no objection to the 
30 facsimile reproduction by anyone of the patent document or the patent disclosure is it 
appears in the Patent and Trademark Office patent file or records, but otherwise 
reserves all copyright rights whatsoever. 



Page 1 of 47 



JGR 1008-1 



REEERENCE TO COM PUTER PROGRAM LISTING APPENDIX 

[0004] A computer program listing appendix comprising duplicate copies of a 
compact disk, named "XXX100X-1-CPLA" accompanies th is application and is 
incor porated bv reference. The comp uter program listing appendix includes the 
following files: 



Detault-XSLl.txt 
Default-XSL2.txt 


y Kbytes on aisK 
7 Kbvtes on disk 


created iviarcn zuio 
created 03 March 2005 


JSP CODE.txt 


22 Kbvtes on disk 


created 03 March 2005 



BACKGROUND OF THE INVENTION 

10 [0005] Electronic commerce between businesses has gained substantial 

momentum. Electronic marketplaces and XML or similar documents have begun to 
replace traditional EDI formats for commerce-related documents. Still, many 
businesses, particularly small and medium-sized businesses, have not adopted 
automated EDI or XML document processing. Whatever their size, many businesses 

15 face the prospect of an expedited implementation of EDI or XML document 

processing. It remains easier for large trading partners to generate XML or similar 
documents than it is for small to medium-sized businesses to adopt the technology 
needed to process them. In addition, a full scale conversion to EDI or XML 
transaction processing may involve far more documents than a business can 

20 practically convert in a workable time frame or on a reasonable budget. 

[0006] One problem with the implementation of EDI or XML transaction 
processing is the complexity and cost of procedural programming to process business 
documents. Procedural programming, otherwise known as hard coding, requires 
much effort to describe document transformations and manipulations in procedural 

25 terms, using programming languages such as Java and C++. This effort translates into 
time for implementation and cost of implementation. 

[0007] In some domains or problem spaces, declarative programming has been 
introduced. It is generally hoped that so-called declarative programming can make 
program customization accessible even to non-programmers. At the same time, it has 
30 been recognized that declarative programming is best when applied to a limited 

domain. Accordingly, declarative approaches are narrow and tailored, not generally 
applied. 
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[0008] Therefore, in the domain of exchanging self-defining, structured 
documents, it is desirable to develop declarative methods and components for 
simplifying the handling of documents. Declarative methods and components can 
improve interactions with users, particularly in the areas of producing documents, 
5 presenting error messages and searching for documents. 

SUMMARY OF THE INVENTION 

[0009] The present invention includes a method and device for declarative error 
handling and presentation. A further aspect of the present invention is extending 
XSLT's document() function to merge one or more error documents with a primary 
10 document for display. Additional aspects of the present invention are described in the 
claims, specification and drawings. 

BRIEF DESCRIPTION OF FIGURES 

[0010] Figure 1 is an overview of the user interface for an xCBL mailbox. 
[0011] Figure 2 is a sample screen display of a folder list, as part of a user 
15 interface. 

[0012] Figure 3 is a sample screen display for a list of documents within a folder, 
as part of a user interface. 

[0013] Figure 4 is a sample screen display for a indicating a reply document type. 
[0014] Figure 5 is the sample screen display for searching on a selected document 
20 type, as part of a user interface. 

[0015] Figure 6 is a block diagram of activities involving two trading partners 
communicating through a document exchange system. 

[0016] Figure 7 is an application flow providing additional detail of activities 
involving two trading partners communicating through a document exchange system. 
25 [0017] Figure 8 is a block diagram of a self-describing, structured document. 
[0018] Figure 9 illustrates participants in a marketplace. 
[0019] Figure 10 is a database schema for a data structure that may be used to 
practice aspects of the present invention. 

[0020] Figure 1 1 is one architecture for software components that handle generic 
30 documents. 

[0021] Figure 12 is a user interface and processing diagram, including validation 
of user created documents. 
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[0022] Figure 13 is a user interface for replying to a request for quote with a 
quote. 

[0023] Figure 14 is an action sequence for replying to a document. 
[0024] Figure 15 is a sequence diagram illustrating use of a servlet to control 
5 responses to a user action request. 

[0025] Figure 16 is a sequence diagram illustrating interaction between a servlet, 
interpreter and data structure engine, in response to data from a user. 
[0026] Figure 17 is a block diagram illustrating posting of data and some of the 
components involved in responding. 
10 [0027] Figure 18 is a simplified flow chart for a method of updating a self- 
describing, structured document. 

[0028] Figure 19 illustrates a protocol for updating a self-describing, structured 
document corresponding to one of a plurality of document schemas. 
[0029] Figure 20 is a flowchart overview of validation. 
15 [0030] Figure 21 is a flowchart overview of a method of searching a plurality of 
self-describing structure documents. 

[0031] Figure 22 a flowchart overview of preparing documents for searching. 
[0032] Figures 23-26 illustrate data tables used to prepare documents for 
searching. 

20 DETAILED DESCRIPTION 

[0033] The following detailed description is made with reference to the figures. 
Preferred and alternative embodiments are described to illustrate the present 
invention, not to limit its scope, which is defined by the claims. Those of ordinary 
skill in the art will recognize a variety of equivalent variations on the description that 
25 follows. 

[0034] Figure 1 depicts a user interface view of a system for handling generic 
business documents exchanged among trading partners. This illustrates an 
environment in which aspects of the present invention may be practiced. A user of a 
document exchange system uses a computer, terminal or other workstation to access a 
30 login screen 111. Standard login and authentication protocols can be followed. After 
a successful login, a user is presented with an initial mailbox screen 112. Figure 2 
depicts a sample initial screen. The user's choices from the initial screen may include 
folder management 121, document searching 122, listing of documents in the selected 
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folder 123 or selection of a particular document type of interest 124. Some of these 
options may be omitted or others may be added to a system. The folder management 
screen 121 provides typical functions for creating, deleting, renaming folders, etc. The 
document search screen 122 allows a user to select a document type and search on 
5 various criteria that are adapted to the selected document type. Figure 5 depicts a 
sample search screen. The list of documents in a folder screen 123 can be reached 
from either the initial screen or from a document search screen. It provides various 
information about documents in a folder, as shown in figure 3. The document type 
selection screen 124 can be implemented to allow a user to create a document from 
10 scratch. When a user selects a particular type of document to compose, the system 
can respond with a document compose screen 134 that includes the fields to be 
completed. 

[0035] From the list of documents in a folder screen, the user can export a 
document 131, read it 132, or use it as a basis for a new document 133, either by 
15 replying to or copying the base document. The document may be exported as an 
XML, PDF, CSV, HTML or other-formatted document. Standard or user-supplied 
export filters can be implemented. 

[0036] The processing of a user request to view a document can be understood by 
reference to the co-pending application for A Method and Apparatus for Viewing 

20 Electronic Commerce-Related Documents at pp. 5-52 and the figures cited therein. In 
general, a series of style sheets can be constructed for displaying documents. These 
style sheets may be written in XSLT, or another transformation language applicable to 
the data type of the documents. A series of style sheets may be written, from generic 
to highly customized. A rule selector can be used to select among the available style 

25 sheets based on criteria such as document type, marketplace identity, sender identity, 
receiver identity, portal identity or other selected criteria. A directory tree, database 
or other data structure can be used to access style sheets based upon the criteria used. 
[0037] A user can select among document types for a resulting reply document 
133. The available document types for a resulting reply document depend on the 

30 document type of the starting document type, for instance a starting document 

selected from a list of documents 123. Figure 4 is a sample screen from which a user 
selects a document type 442 for a resulting reply document. The reply document type 
can be the same as the starting type, for instance when a user is copying and reusing a 
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previous order as a template. The trading partner 443 may be identified by a full 
name, a short name and/or a unique identifier string. 

[0038] Figure 2 provides additional details of the folder management screen. The 
user is presented with standard screen functionality such as home, help and log off 
5 21 1. The current user and user organization are presented in the header 212. This is 
helpful for users who may belong to more than one organization. Options for 
accessing additional screens, such as the in box, composing a document, searching, 
addressee's and folders are presented. For figure 2, the active option is folders. 
Several columns of information about folders are provided, including folder name 

10 222, number of documents in a folder 223 and number of unread documents in the 
folder 224. Additional columns of information can be provided. 
[0039] Figure 3 provides additional details of the file list screen. General aspects 
of the screen follow the format of other screens, e.g. 21 1, 212, 221. The current 
folder being viewed and other folders available for view can be listed in the 

1 5 navigation box 331. The checkboxes 332 are provided for selecting individual 

documents to delete or to move to a folder. A column identifying the trading partners 
from whom documents originated 333 is provided. Date and time information and 
document types also are provided 334, 335. Icons for the document also can be 
provided 336. From the envelope icon, the user will know if the document has been 

20 read or not and also may know if it has been forwarded or replied to. From the export 
icon, the user can export the document. The same functionality can be provided for 
exporting a series of documents that have been checked. From the clip icon, the user 
can know if there are attachments associated with the document. The clip icon may 
allow direct access to a list of attachments or to the attachments themselves. 

25 [0040] The document type selection screen of figure 4 can lead to either a search 
or a reply action, depending on the context. In figure 4, a trading partner name and 
document type may be described in the banner 441, if they have been selected. 
Selection of a document type provides a context for either searching or replying. 
Figure 5 depicts a sample search screen that includes many of the same features as 

30 other sample screens, e.g., 211, 212, 221, and 331. One or more field selection filters 
5 12, 5 13 ar e supplied. The values accessible by the pull down menus of these filters 
are context sensitive to a selected document typo, if the document typo is selected by a 
filter 518 or has boon selected by context in a prior scroon. Only the field types that 
are valid for a particular document typ e appear in the pull down menu, once a 
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document typ e has been selected. One or moro value specification fields 5 1 A also are 
provided. These value specification fields are context sensitive to the document 
fields. The user's entry can bo checked for format and data typo as the user enters the 
data. Th e combination of field selection filters and value specification fields, context 
5 sensitive to the document type selected, enables a generic interface for searching 
across different document types. In addition to generic field handling, additional 
filters can b e provided to search by date 515, document status 516, trading partner 517 
or other field. A variety of interfaces can be used to implement these filters, such as 
pull down menus, radio buttons, checkboxes, or blanks to fill in. A list of folders to 
10 search in 519 can be dynamically generated, to match the list of folders in the 
navigation box 221, 331. 

[0040A1 Figure 5 depicts a sample searc h screen that includes many of the same 
features as other sample screens, e. g.. 21 1. 212. 221. and 331. One or more field 
selection filters 5 12. 5 1 3 are supplie d. The values accessible bv the pull down menus 

15 of these filters are context sensitive to a selected document type, if the document type 
is selected bv a filter 518 or has been selected bv context in a prior screen. Only the 
field types that are valid for a particular document type appear in the pull down menu, 
once a document type has been selected. One or more value specification fields 514 
also are provided. These value specification fields are context sensitive to the 

20 document fields. The user f s entry can be checked for format and data type as the user 
enters the data. The combination of field selection filters and va lue specification 
fields, context sensitive to the document typ e selected, enables a generic interface for 
searchin g across different document types. In addition to generic field handling, 
additional filters can be provided to search b v date 515. document status 516. trading 

25 partner 517 or other field. A variety of interfaces can be used to implement these 

filters, such as pull down menus, radio buttons, checkboxes, or blanks to fill in. A list 
of folders to search in 519 can be dynamically generated, to match the list of folders 
in the navigation box 221. 331. 

[0041] Figure 6 is a block diagram, at a very high level, depicting flow through 
30 activities related to exchange of documents between trading partners. A trading 
partner 601 using a connector sends a business document to a document router 606, 
which routes the document to a generic document handling service 609 within a 
service environment 608. The generic document handling service does some 
processing and, assuming no fatal error, stores the document inside database 607. 
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Later, another trading partner 602 using a browser or other software adapted to 
communicate with the market site 603 accesses the Web server 604 running a 
document access servlet 605. The trading partner reads the document and, optionally, 
creates a response or uses the document as a basis for creating a new document. The 
5 second trading partner can access and create generic documents using a standard Web 
browser or other software. The servlet retrieves the starting document from the 
database 607. After a response or new document is created, the document can be sent 
to another trading partner 601. All of the functions of the market site 603 can be 
hosted on a single server. In some implementations, it is desirable to have separate 
10 servers for the router 606, the services 608, the database 607 and the Web servers 604. 
Additional servers or families of servers may be added for load balancing, high 
availability and/or security reasons. 

[0042] Figure 7 is a block diagram depicting an alternative system. Interacting 
with the system are an entity 701 which sends a document to the system and a user 

15 702 who interacts with the document stored by the system. The entity sends the 

document to a server 708 via router and communication channels that are not depicted 
in the figure. The document may reach the server 708 based on the addressee of the 
document or a combination of addressee and document type, or it may be sent directly 
to a location specified by the sender. For instance, a global directory may be 

20 published that identifies locations to which participants in a marketplace desire for 
various types of documents to be sent. The locations may be specified in the form of 
market participant IDs or URLs. A market participant may have multiple IDs or 
URLs. 

[0043] A document being sent is typically a self-describing, structured document. 

25 XML documents are a common type of self-describing, structured documents. Fields 
within this document are self-describing, as the fields are tagged. A sample document 
having two different types of tagged fields is illustrated in figure 8. The document 
800 may have one or more parts 830, 840. For instance, the document may include a 
MIME header and an XML body. A MIME header may be compliant with RFC 822. 

30 The header 830 includes a plurality of tagged fields 83 1-833. The body 840 also 
includes a plurality of tagged fields 841-849. Alternatively, the document may have 
only one part or one type of tagged fields. These tagged fields may comply with a 
schema, such as an xCBL schema by Commerce One or a CXML schema by Areba. 
A scheme is characterized by tagged fields having types and super types. Types 
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inherit properties from the super types on which they are based. Types are defined 
based on their super types and having additional properties. Other standards to which 
tagged fields may comply include Sox by Commerce One, ECX, the OAGI standard 
of Open Applications.org, the BizTalk standard by Microsoft, the Rosetta net standard 
5 by Rosetta Net.org, and EDI X 1 2 A32. 

[0044] Referring to figure 7, the entity which sent a document to the system 701 
may be an electronic trading partner or otherwise an electronic correspondent of the 
entity to which user 702 belongs. The relationship of trading partners or electronic 
correspondence is illustrated in figure 9. The trading partners participate in the 

10 trading network 900. This network may be hosted by a single entity or it may be a 
collaboration of networks hosted by distinct entities. The trading partners may both 
use the same host or they may use different hosts which route messages among 
themselves. Two trading partners 860, 880 are illustrated. Participants on behalf of 
the trading partners 861, 381 may be systems or human beings. Referring again to 

15 figure 7, the entity 701 which sends the document to the server 708 may be either a 
system or a human being. Purchasing systems are examples of entities which 
generate self-describing, structured, tagged field documents and send them to 
systems. 

[0045] On server 708, one or more services 711-713 may be available. One 
20 service may receive the document 711. The same or another service 712 may 
persistently store the incoming document, for instance in a database 707. One or 
more databases may be used to store data useful for electronic commerce or other 
document exchange. A database may include a repository of schemas 741 for 
standard and entity-defined business documents, a repository of JavaBeans 742, C++ 
25 structures, Pascal records or scripts useful to electronic commerce, a document map 
repository 743 for translation of documents from one format to another (e.g., the 
xCBL format to an export format) and for transformation of documents from one type 
to another (e.g., from a request for quotation to a quotation.) The database may further 
include a report layout repository 744 and a presentation layout repository 745. The 
30 presentation layout repository may include declarative transformations for changing 
documents from a Sox document format to an HTML format, and back again. The 
transmission properties data describes the transport information needed to sent a 
business document to a recipient. For example, SSL security credentials can be stored 
as transmission properties. A trading partner directory is also useful. The trading 
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partner directory may, as described above, identify URLs to which the sending entity 
701 transmits documents. The persistent storage for data 707, 741-47 may be on a 
single data storage unit or multiple units. Persistent document storage need not be 
part of a database. An indexed flat file would suffice to store XML-compliant 
5 documents. The services host 708 may also host an indexing service to index one or 
more of the tagged fields. Alternatively, a database system managing the persistent 
storage or other subsystem may index documents for retrieval. An incoming 
document may or may not be validated against schema from a schema repository 741, 
before it is persistently stored. A schema may be used to interpret the document. One 

10 or more JavaBeans or Scripps may be used to act on the document before it is stored. 
[0046] One schema for persistently stored documents is illustrated in figure 10. 
In this schema, a document and its header are captured in structure 1020. If this 
document is a copy or a reply based on an original document, the original document is 
stored in structure 1023. A copy or a reply document is associated with a special 

15 folder 1024. Document attachments are captured in structure 1040. Sets of valid 
document types and document statuses are maintained in structures 1010 and 1030, 
respectively. The one-to-many connections between structures 1010, 1030 and 
structure 1020 indicate that only one document type and one document status are 
y allowed per document. To support searching, searchable fields are listed in a data 

20 structure 1012, and may be assigned unique or non-unique alias names. Information 
regarding searchable fields is listed in a separate data structure 1022. Other data 
arrangements may equally well practice aspects of the present invention. 
[0047] Persistent storage of the incoming document may be accompanied by 
various processing steps. The original document, prior to normalizing, may be stored 

25 in a database. Envelope properties may be extracted from the envelope and 

normalized in a database or other storage. A predefined list of indexed fields, by 
document type, may be consulted and those fields indexed. Generic document 
properties, such as date and status, may be extracted from the envelope. The envelope 
itself may be separately stored. Attachments may be separately stored. Unneeded 

30 white space may be removed and name space abbreviations used to reduce storage 
requirements. 

[0048] Returning to figure 7, the service 713 may advise the user 702 of receipt of 
the document by messaging, posting any other practical means. One or more users 
may be given notice, based on the identity of the sending entity, the identity of the 
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receiving entity, the document type or other characteristics of the document. One 
syntax for subscription by a user is subscription = sender ID.recipient ID.document 
type. To receive all Order documents from a particular sending entity, a user could 
subscribe as follows: subscription = SI 234.*. Order. This subscription would cause 
5 service 713 to notify user 702 of receipt of order type documents from sending entity 
SI 234. Security features of the system would, of course, restrict access appropriately. 
Notice may be given by messaging, such as e-mail or Lotus Notes messaging. A 
message may include a subject, such as, M five new documents received," header text 
generally stating that new documents have been received or that old documents 

10 remain to be viewed. The e-mail may further include body text providing the date, 
number and sending party's identities for documents received. The body text may 
further provide detail regarding individual documents received, such as the document 
type, sender identity and date or time of receipt. The user interface may identify the 
location for viewing the document, such as by a click through URL. Alternatively, 

15 notice may be given by posting at a location to which the user has access. A 
combination of notice formats may be used, such as posting followed by e-mail 
follow-up in the user does not promptly access listed documents. E-mails based on 
the status of accessing a document or a post notice may be sent periodically and may 
include increasingly strong wording or additional addresses, based on the type and/or 

20 aging of the received document. 

[0049] A system 704 may be based upon a web server and a servlet container, for 
instance, compatible with JRun 3. A user interface application 721 may include a 
homepage 721, an in box 722, one or more services to read the document and/or its 
attachments 723, services for folder management 724, customized folders 725, 

25 searching for and listing documents. An additional service may provide access for 
downloading template documents 728. The web server may include Microsoft's 
Webserver software, a Java interpreter such as JRun 3 and a servlet container. A data 
storage interface may use the resources of a database. A first collection of services 
720 is illustrated as being coupled with a transformation engine 730. The 

30 transformation engine may include selection logic 732 to select the style sheet for 

transformation purposes and transformation logic 73 1 which applies a style sheet to a 
document. 

[0050] Figure 1 1 depicts a further alternative environment in which aspects of the 
present invention can be practiced, similar to the environments depicted in figures 6 
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and 7. A web server 1111 takes HTTP requests and makes HTTP responses. A 
generic document handling facility takes advantage of the web server resources 
through a program interface. One useful API is Sun Microsystems Java servlet. The 
so-called servlet technology provides a simple, consistent mechanism for providing 
5 access to web server services. A servlet written in Java can provide a component- 
based, platform-independent method for building Web-based applications. A single 
servlet application may be integrated with a variety of web-enabled application 
servers such as BEA WebLogic Application Server, IBM WebSphere, iPlanet 
Application Server others. Complementary to servlet technology is Java Server Pages 

10 (JSP) support 1 1 14. The JSP technology is an extension of servlet technology that 
supports authoring of HTML and XML pages. JSP facilitates mixing dynamic 
content with static templates. JSP supports encapsulation of logic to generate content 
dynamically. The dynamic content logic can be accessed from the template page. 
The servlet runner 1112 resident on the web server may be JRun or a similar Java 

15 environment. Alternatively, a different program interface to the web server may be 
used with a different programming language. The servlet runner supports the servlet 
interface for access to the web server. The servlet runner supports the servlet 
controller 1 1 13, invocation of JSP pages 1 1 14, and a variety of applications 1 121-26. 
Among these applications, the data access layer is an abstraction layer for access to 

20 the database 1151. The data access layer is present on each server or in each 

application environment that accesses the database 1 133, 1 144. XMLPres 1 122 is a 
style sheet engine that handles extended XSLT style sheets for transformation of 
XML into HTML. The rule selector 1 123, as described in the co-pending application, 
provides access to default or a customized rules and templates that match parameter 

25 such as document type and trading partner. The XML engine parses and processes 
XML documents. For XML, records can be parsed and processed using DOM, SAX 
or any other programming model. Folder management is provided 1 125. Software 
and resources for processing browser forms with embedded pass specifications are 
also provided 1 126, as described further below. E-mail notification 1131 may be 

30 structured with an e-mail module 1 132, a data access layer 1 133, and e-mail 

management routines. The e-mail module will utilize routines of the data access layer 
and the e-mail management library. Sun Microsystems provides a library of e-mail 
management routines complementary to its servlet technology. The overall generic 
document exchange service 1 141 can be hosted within a services environment 1 142. 
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The generic document exchange service 1 143 may include logic in resources for data 
access 1 144, XML transformation is 1 145 and XML searching and processing 1 146. 
Data accessed and utilized by these routines may be stored in multiple databases 
1 151, 1 152. A database of documents may be one component and market site data 
5 may be another, the market site data including a directory compliant with a 
lightweight directory access protocol. 

[0051] Figure 12 is a block diagram of a user interface and declarative data. This 
figure provides additional detail beyond the detail of figure 1 . The initial three 
screens, for displaying a document 132, selecting a document type 133, and 

10 composing a reply or new document 141 are the same as in figure 1. Figure 12 
depicts the use of declarative data for a mapping selector 1231, for data 
transformation mapping 121 1, and for display transformation 1212 in conjunction 
with the document type selection screen 133. The mapping selector 1231 provides a 
list of document types that can be produced from a selected starting document is 

15 accessed and incorporated in the user interface. The types of resulting documents that 
can be produced may depend on the marketplace, trading partner and other factors, as 
well as the document type of the starting document. From a starting document and 
selection of a document type for a resulting document, data transformation mapping 
121 1 is applied to generate a draft resulting document from the starting document. 

20 The transformation mapping should ensure that the resulting document is well 
formed, when the starting document is well formed. For XML to XML 
transformation, the declarative transformation mapping may take the form of an 
XSLT style sheet, potentially with extensions to XSLT. Other forms of declarative 
schema-to-schema mapping may also be used. Display transformation mapping 

25 utilizes declarative display format data 1 121 to transform the underlying data for use 
in the user interface, for instance, to transform XML to HTML they can be viewed by 
a browser. Following document type selection 133, application of declarative data 
from a mapping selector, data transformation mapping, and display transformation 
mapping is used to produce a document updates screen 141. In one embodiment, 

30 application of one or more declarative transformations to the starting document 
produces a user interface form. The user interface form includes a plurality of path 
specifications for fields corresponding to the document type of the resulting 
document, starting values based on the starting document for at least some of the 
fields in the resulting document, and values to be completed for other fields in the 
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resulting document. Field labels also may be included, either as data or along with 
other page formatting information. Alternatively, all of the fields may be populated 
and none left to be completed. Some fields may be editable and others not editable. 
The path specifications may conveniently be implemented as HTML hidden fields or 
5 otherwise as non-displaying fields. They can be displayed, for instance, for 

debugging. XPath is one convention that can be used for path specifications to nodes 
or fields within an XML document. An alias for an XPath path specification also may 
be used, in conjunction with a lookup from the alias to the full path specification. 
Aliases can double as field labels. 
10 [0052] Sample excerpts of a document to display transformation 1212 for a main 
processing routine and display of header information with embedded path 
specifications foHows fare reflected in the file "Default XSL l.txt" on the 
accompanying CD-ROM of source code. 

Pefa u l t.x 6l 

15 

<?xml vorc i on = "1.0" ?> 
■ <xs l :sty le sh ee t vorsion="1 -0" 
xm l ns:xel="http://ww^ 

xm l ns:oxt="http://wwwxom xmlns:cb l ="urn:x- 

20 comm e rc e on e : 

document:com:comm e rc e on e :XCBL30:XCBL30. s ox$1.0'' 

xmlns:xm g "http://wwwxomm e rc e on e xom/xcb l ma il box ,, > 

<xs l : i nc l ude hr e f = " s ch e matron e rror.xs l " /> 

<xs l : i nclude hrof = "h e ad e r__d i sp l ay.x 6 r /> 

25 <xsl: i ncludQ href="d e ta i Ldisplay.xsr /> 

<xs l : i noludo hr e f = " s ummary_di 6 p l ay.x6r /> 

cxol: i ncludo hrof= ,, l r:Q^oto:Quote_variab le ■xsl$1■0 >, /> 

cxGl:doc i mal - format namo = "DE I T" docima l soparator = "," grouping - 

soparator = "." /> 

30 cxchdoc i ma l- format namo = "FR" docima l- soparator="," group i ng - 

ooparator="" /> 
■ <xc l :tomp l ato match = 7"> 



Thio i o for display i ng Schomatron orrors 

35 — > 

- <xsl: i f t e st = " 6 tring($xm:ha6Sch e matron) = 'tru e '"> 

<xsl:var i ab le name = "ro s u l t 6 " coloct = "docum e nt( , e rror:/// 

s ch e matronConformanc e .xmr)" /> 

- <xsl:cal l- tomplato namo = "ErrorD i6 p l ay e r"> 

40 <xc l :w i th - param namo="confdoo" s e l e ot^'^r e su l t s " /> 

<xo l :w i th - param namo=" i dmap" soloct= "Sschomatronmap s ' /> 

</xs l :cal l- tomplat e > 

</xs l :if> 
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I f tho xm l i nstanco hac orror, disp l ay orror f i olds w i th 
f i o l d va li dation error 

- <xs l :choos e > 

5 - <xcl:whon tost=" s tr i ng($xm:ha s Error) = , tru e " , > 

<xs l :var i ab le namo = "ErrorDocument" s e l e ct = "dooum e nt(' e rror:/ 
//inMomoryError 1 )" /> 
- <xs l :var i ablo namo - ,l Prof i xes"> 
<ompty /> 
10 </xs l :var i abl e > 

<xo l :ca ll tomp l ato namo="PisplayHoad e r,Error"> 
<xc l :w i th param namo = "Prof i xos" so l oct="$Profixos" /> 
<xcl:with - param namo = "ErrorDocument" 
Goloot = "$ErrorPooumont" /> 
15 <xsl:w i th - param namo = "ErrorCodoMap s " so l oct = "$codomaps'' 

P> 

c/xG l :oa ll tomp l ato 

cxohoa ll tomplato namo="P is playD e ta i LError !, > 
<xe l :with param namo="Prof i xe s " so l oot = "$Pr e f i xes" /> 
20 <xs l :w i th - param namo = ,, ErrorDocumont" 

so l oct = "$ErrorDocum e nt" /> 
<xc l :w i th - param nam e= n ErrorCodoMaps" solocWSood e maps" 

</xcl:call - tomp l at e > 
25 <xe l :ca ll- tomp l ato namo = "Di s p l aySummary" /> 

</xsl:wh e n> 

If tho xml i nstanco doesn't Gontain error, disp l ay all 
f i o l ds without any error 

30 — > 

- <xsl:oth e rwis e > 

<XG l :call tomp l ato namo="D i6 p l ayHoader J^oError" /> 
cxclicall tomplato namQ="Di 6 p l ayDota i LNoError n /> 
<xG l :ca l l - t e mplate nam e= "Disp l aySummary" /> 
35 </xc l :othorw i s e > 
</xG l :choo 6e > 
</xs l :tomp l ate> 
</xs l :sty l eshe e t> 

40 Head e r di s p l av.x sl 

<?xm l voroion-"1.0" oncod i ng^"UTF - 8" ?> 
■ <xcl:styloshe e t vorsion = "1 .0" 
xm l nG:xsl="http://www.w3.o^ 
45 xm l nG:oxt="http://www^commorcoono■com/xm l pros ,, xmlnciGbh'urnix 

comm e rc e on e : 

documont:com:Gommorc e on e :XCBL30:XCBL30. s ox$1.0' 
xm l ns:xm="http://wwwxomm e rcoon o .com/xcblma il box >> > 

<xsl: i nc l ud e hrof = "error.x 8l " /> 
50 <xc l : i nc l udo hrof="hoador_party_d is play.x 6l " /> 
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■ <xs l :tomp l ato namo="P is playHoador_Error"> 

This i s th e pr e f i x to nam e cpaco b i nd i ngs u se d in th e 
location 

— -> 



<xs l :param nam e= "Prof i x e s" /> 
-4- 



Th i s is th e orror document to retr i ovo orrors from 



10 <xc l :param namo^'ErrorPocumont" /> 

Thic i o a rosu l t troo fragm e nt that maps error cod e s 
to loca li z e d descriptions 

--> 



15 <xs l :param nam e ="ErrorCod e Map s " /> 

- <TABLE co ll padd i ng="1 " co ll epac i ng="0" border="0" width = "100%"> 
■ <TR olacs="ListHoader"> 

■ <TD a li gn=" l oft" co l span^" o l ass="L i stHoadorToxt"> 

<xsl:valuo - of so l oot="$QuotcHoader" /> 
20 </TD> 

</TR> 
- <TR> 

■ cTD o l asc= "Statu s H e adorSma ll Now" width= "50%"> 

<span cla s6 ="Requ i r e dF i o l d">*</span> 
25 <xcl:va l uo of so l oct="$QuotoRofNum" /> 

</TD> 

cTD class ^ "StatusH e adorSma ll Now'' width = "50%"> 
<span cla 6 S = "Roqu i r e dF i o l d">*</span> 
<xo l :valu e- of s ele ct="$Quot e l S 6ueDat e " /> 

30 -( 

cxokvaluo of co l oct-"str i ng($xm:DATET I MEMASK)" /> 

</TD> 
</TR> 

35 - <T R > 

■ <TD class= "E l omontSty le " width = "50%"> 

cxohvariab l o namo="xpath">/Quoto/QuotoHoader/Quote l D/ 

Rof e r e nce/R e fNum</xs l :variab le > 
< i nput type="hiddon" namo="[ooncat('XPostChango:', $xpath)}" 

40 valuo="" /> 

e i nput clacc-"Elem e ntStylo" typo = "toxt" 

namo="(concat('XPo o tContcnt:', $xpath)}" va l uo = "{cbhQuot e / 
cb l :QuotoHcad e r/cbl:Quoto l D/cbl:Rofor e nce/cbl:R e fNum}" 

sizo="20" 

45 onChang e ="java 6 Gr i pt:cotMod i f i cd('[concat('XPostChango;', 

$xpath))');" /> 
■ <xc l :var i ab le namo="R e fNumError s "> 
• <xsl:ca l l - t e mp l at e namo = "ErrorDot e otor"> 
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coloct = " l /Quoto/Quot e Hoador/Quoto l P/Roforonco/RofNum 

cxchw i th param namo="Profix o s" so l octe'SProf i xos" /> 
cxchwith - param namo="ErrorPocum e nt" 

s e l e ct="$ErrorDooum e nt" /> 
cxchwith param namo="ErrorCodoMap s " 
so l ect = "$ErrorCodeMap s " /> 
</xG l :ca ll- tomp l ate> 
</xshvar i abl e > 

- <xs l :if 

toct = " G tr i ng($RofNumError G )! =s tr i ng($NotMappedCon 6 tant) M 

<opan c l acG="ErrorToxtSmaH"> 

<xcl:va l u e- of Go l oGt = ,, $Error" /> 

cxchva l uQ - of G0 l 0Gt = "$RofNumError 6 " /> 
j ■ 

</span> 
</xs l : i f> 
<TTD> 

- <TD olaGS="E lo montStylo" w i dth="50%"> 

<XG l :variablo namo="xpath">/Quot e /QuotoHoad e r/ 

Quot els su e Dato</xs l :var i ab le > 
cinput typo = "h i ddon" namo = "{concat('XPo s tChango: 1 , $xpath)}" 

valuo= ,,n /> 

■ <xc l :var i ablo namo = "DatoError 6 "> 

■ <xsl:ca ll- t e mp l at e nam e ="ErrorD e t e ctor ll > 

cxohwith - param namo="Location" Go l oct = "7Quot e / 

QuotoHoador/Quot elG suoDato 1 " /> 
cxohw i th param namo="Pr o f i xos" Go l oct="$Prof i xos" /> 
cxohw i th param namo = "ErrorDocument" 

s ele ct = "$ErrorDocum e nt n /> 
cxohw i th - param nam e= "ErrorCod e Maps" 
6Q le ct="$ErrorCod e Map6" /> 
c/xG l :cal l- t e mplat e > 
</xGl:var i abl e > 

cxGhparam nam e= "d a t e " s el oct = "cb l :Quot e / 
cbl:QuotoHoador/cbl:Quoto l SGuoDato" /> 

- <xs l : param nam e= "Quot el S 6 u e dPat e "> 

cco: l ookup xm l nG:G e= ' l http://www.commerc e on e .Gom/x 6l t/ 
e xt e n s ion s " xmlnc:ma ill ookup="urn:mai l box:lookup" 
mapnamo="ma il lookup:DateT i m e Formatter" va l uo = "$dat e " 
orrorva l uo= ,,l Can not mapp e d 1 " /> 
</xel:param> 

■ cxo l :choos e > 
- <xsl:wh e n 

toGt= n Gtr i ng($DatoError 6 )! = Gtring($NotMappodCon s tant)"> 
c i nput class="E l omontSty l o" typo="text" 
namo = "[concat( , XPostContont: , > $xpath)}" 
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va l uo=" [ob i : Quote/ 

Gb l :QuotoHoador/cb l :QuotolssuoDato] " o i zo="1 5" 
onChango = "javascr i pt:sotMod i fi e d('{concat('XPo s tChang 

o:\ $xpath))');" /> 
- <span c l acs="ErrorToxtSmaM"> 

-E 

<xsl:va l uo of ooloot="$Error" /> 
<xsl:va l uo - of soloct="$PatoError s " /> 



10 </span> 

</xs l :wh e n> 
- <xsl:oth e rw i se> 

<input o l ass = "Elom e ntSty l o" typo="toxt" 
namo="{concat('XPostContont:', $xpath)}" 
15 va l uo = "{$Quotol ss uodDato}" o i zo = "1 5" 

onChango="javascr i pt: 6 0tMod i f i od('{concat('XPostChang 

oi', $xpath))');" /> 
</xs l :othorwis e > 
</xs l :choos e > 
20 </TD> 

</TR> 

<xs l :oall - tomplat e namo="D i sp l ayParty" /> 
</TABLE> 

< i mg crc="../img/ o pacor.g i f " a l t-"" hoighfr"5" width = "1 " /> 
25 <BR /> 

</xsl:temp l at e > 

cxchtomp l ato namo="D is playHoador_NoError"> 
■ cTABLE co ll padding = "1 " eo ll cpac i ng="0" bordor="0" w i dth = "100%"> 
<TR c l aos="L i stHoador"> 
30 ■ cTD align=" l oft" co l opan="2" o l ass="ListHoad e rT e xt"> 

<xe l :va l uo - of so l oct = "$Quot e H e ad e r" /> 
<fTD> 
</TR> 

- <TR > 

35 - cTD c l ass="StatusH e adorSma ll Now" width= "50%"> 

<span cla6 6= "R e quir e dFie l d">*</span> 
gxc l :valuoof soloct = "$QuotoRofNum" /> 

</TD> 

- <TD G l ass = "Statu s HcadorSma ll Now" width="50%"> 
40 <cpan c l ass = "R e qu i rodFio l d">*</span> 

<xc l :va l uo - of s e l e ct = "$Quot e l s 6u e Dat e " /> 

cxchva l uo of co l oct="otr i ng($xm:DATET I MEMASK)" /> 

45 </TD> 

</TR> 

- <TR> 

• <TD o l ass="ElomontSty l o" w i dth="50%"> 

cxchvar i ablo namo = "xpath">/Quoto/QuotoHoador/Quote l D/ 
50 Rof e r e nc e /R e fNum</xo l :var i abl e > 
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tinput typo="h i ddon" namo="{concat('XPo s tChango:', $xpath)}" 
va l uo = "" /> 

<input class = "El o montSty l o" typo-"text" 

namo="[conoat('XPootContont:', $xpath))" va l uo= "(cbhQuot e / 
cb l :QuotoHoader/cb l :Quot el D/cbl:Roforonoo/cb l :RofNum}" 



ICat(— 



T 



$xpath)}');" /> 

<fTD> 

10 - <TD o l ass^E l omontSty l o" width= p 50% p : 

<xcl:param namo^'dato" soloct = "ob l :Quoto/ 

cb l :Quot e Hoad e r/cb l :Quot el66 u e Dat e '7> 
<xcl:variab l o namo= >l xpath">/Quoto/QuotoHoador/ 
Quot e l6 s u e Dat e </xs l :variab le > 
15 <input typo="h i ddon" namo^tconcatCXPo s tChango: 1 , $xpath)}" 

va l uo = " ,, /> 
■ <xc l :param namo = "Quoto lo suodDat e < '> 

<ce:lookup xm l ns:c e= ' , http://www.comm e rcoon e .com/x 6l t/ 
e xt e n s ions" xm l ns:maillookup - "urn:ma i lbox:lookup" 
20 mapname = ,, maillookup:Dat e T i moFormatt e r" va l uo = "$dat e " 

errorva l uo s ni Can not mapp e d 1 " /> 
</xs l :param> 

dnput clacs = "ElomontSty le " typo = "t e xt" 
namo = M {conoat( l XPo s tContont: , , $xpath)}" 
25 va l uo = "{$Quoto ls 6u e dDato} M sizo="1 5" 

onChango = "javascript:sotModif ie d('[concat('XPostChangG:', 

$xpath)}');" /> 

<JTD> 
</TR> 

30 <xs l :cal l- tomp l at e namo = ,l D is playParty ,> /> 

< i mg src="../img/ s pacor.g i f" a l t = "" hoight="5" w i dth^T' /> 
<BR /> 
</TABLE> 
</xs l :tomp l at e > 
35 </xc l :stylosh e et> 



[0053] A draft resulting document also may be generated, in the process of 
producing the user form. This document may be produced according to a declarative 

40 transformation of a starting XML document into a draft resulting XML document. 
The draft resulting document may include starting values from the starting document. 
It also may include default values for some fields and directions for completing other 
fields. The draft resulting document may be stored in memory according to a 
document-object-model (DOM) or another tree-based representation. Alternatively, 

45 the draft resulting document may be stored on disk or in memory in a form 

compatible with Simple API for XML (SAX or SAX2) or another event-based access 
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model. Or, an event-based API can be used to construct a tree, or traverse an in- 
memory tree. When a draft resulting document is generated, in addition to a form, the 
draft resulting document may be maintained in memory while the user works from the 
form and a document ID can be maintained with other state information for the draft 
5 resulting document. Alternatively, a document ID and related information can be 
transmitted with the user form, even in a stateless fashion, and the draft resulting 
document constructed after the user's updating of the form. A draft resulting 
document can be transformed with a display transformation to generate the user form. 
The display transformation may be generated with an XSLT stylesheet or another set 
10 of declarative data. 

[0054] Sample excerpts of a document to document transformation 1211 from a 
request for quotation to quotation follows, including portions of a main processing 
routine and a party copy routine s are reflected in the file "D efault XSL2.txt" on the 
accompanying CD-ROM of source code. 

15 D e fau l t. x st 

- <xc l :Gtylosh ee t vors i on = "1 .0" 

xmlns:xsl= ,, http://www,w3.org/1999/XSL/rran s form n 

xmlns: e xt = ' l http://wwwxomm e ^c e on e xom/xm l pr e s l, xm l ns:cbl="urn:x - 

comm e rc e one: docum e nt:com:comm e rc e on e :XCBL30:XCBL30.sox$1 .0" 
20 xm l ns:xm = ll http://www.comm e rc e on e xorr^xcb l ma il box 1 '^ 

<xol:output m e thod = "xm l " ind e nWy e s" om i t - xm l deo l aration - n y es " /> 

<xsl: i no l ud e hr e f = "r e f e ronco_copy-xs l " /> 

<xs l :ino l ude hrof="party_oopy.xsr /> 

<xs l :inc l ud e hrof = "l i n e it e mnum_copy-X6 l " /> 
25 <xs l : i ncludo hr e f = " i t e m i d e ntif ie r 6 _copy.x 6l " /> 

<xo l :includo hrof=" i dontif i or_copy-X 6l " /> 

<xs l :inc l ud e hr e f = "tota l quant i ty_copy.xs l " /> 

■ <xc l :tomp l ato match = "/"> 

- <xs l :proc e ssing -i nstruct i on namo = n s oxtyp e "> 

30 <xs l :toxt>urn:xcomm e rc e on e : 

documont:com:commercoono:XCBL30:XCBL30.GOX$1.0</xG l :toxt> 

</xG l :proGOGG i ng -i nstruct i on> 

■ <Quot e > 

<xc l :app l y tomp l atos solect="cb l :RoquostForQuotation/ 
35 GbkRoqu e stQuot e Head e r" /> 

<xs l :apply - tomplat e s s e l e ct = "ob l :R e qu e stForQuotat i on/ 

cb l :ListOfR e qu e stQuot e Dota ils '7> 
cxchapply tomp l atoc eoloct = "cb l :Roque 6 tForQuotation/ 

cbkR e que s tQuot e Summary" /> 

40 </Quote> 

</xcl:tomp l at e > 

■ <xcl:tomplato match = "cb l :Roqu e stQuotoH e ad e r "> 

cxchcal l tomp l ato namo = "OutputQuotoHoador" /> 
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</xs l :t e mplate> 

■ cxcktomp l ato match = "cb l :L i6 tOfR e quo s tQuotoDetai l 6"> 

<xGl:ca ll- tomplato nama= "OutputL io tOfQuotoPotai l s" /> 

</xs l :t e mplate> 

5 - <xs l :tomplato match= "cbhRequ es tQuotoSummary "> 
<xs l :ca ll- tomp l ato namo = ,, OutputQuotoSummary n /> 
</xs l :t e mplat e > 
- <xcl:tomplato namo="OutputQuotoHead e r"> 

■ <QuotoH e ad e r> 

10 <Quoto l ssuoDato /> 

- <Quot el D> 

cxskapply - tomp l atos SQ l oct = "cb l :RoquostQuoto l D" /> 
</QuotolD> 

- <Quot e Party> 

15 <xo l :app l y - tomp l atos so l oct = ,, cbl:RoquostQuotoParty" /> 

</Quot e Party > 

<xGl:oa ll- tomplato namo = "OutputQuotoCurroncy" /> 
<xs l :cal l- tomplato namo="Out|3UtQuoteT©rm 6 0f Paym o nt" /> 
</Quot e H e ad e r> 
20 </xsl:templat e > 

■ <xs l :t e mplate name = "OutputLi s tOfQuotoDota il s "> 

- <L i stOfQuotoDota il s> 

■ <xs l :for - oaoh s ele ct = "Gb l :R e qu e 6tQuot e D e ta i l s "> 
- <QuotoDotai l s> 

25 <xGl:ca ll- tomp l ato namo = ,l OutputQuot e ltemTypo ,t /> 

<xGl:ca ll- tomp l ato namo= "OutputQuot ol t o mDota il ' 1 /> 
</Quot e D e ta i ls> 
</xsl:for -e ach> 
</L i GtOfQuot e D e ta i ls> 
30 </xG l :templat e > 

■ <xGl:tomp l ato nam e = ,, OutputQuot e Summary"> 

- <QuotoSummary> 

<xcl:copy of Goloct="cb l :TotalNumborOfL i ne l t e ms" /> 
</Quot e Summary> 
35 </xG l :tomplat e > 

■ <xc l :tomp l ato namo="OutputQuote l tomTypo"> 

- <Quoto l temTyp e > 

■ <Quot e Typ e > 

cQuotoTypoCodod /> 
40 </QuotoTyp e > 
</Quot el t e mTyp 8 > 
</xG l :tomplate> 

<xc l :tomp l ato namo = ,, OutputQuot el tomDotai l "> 

■ <Quoto l t e mD e ta i l> 

45 <xcl:app l y tomplatoc 

GQloct="cb l :Roqu o6 tQuote l tomDotail/cbl:Ba6 el tomDota i l" /> 

</Quot el tomD e tai l > 

- <QuotePr i G i ngD e tai l > 

- <Pr i c i ngD e ta il > 
50 - <ListOfPr i co> 
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- <Pr i c e > 

- <UnitPr i ce> 

<UnitPr i c e Va l u e /> 
- <UnitOfMoasuromont> 
5 <UOMCodod /> 

</Un i tOfMoasur e m e nt> 
</UnitPrice> 
</Pr i c e > 
</ListOfPr i co> 
10 - <Tota l Va l ue> 

- <Mon e taryValu e > 

<Mon e taryAmount /> 
</Mon e taryVa l u e > 
</Tota l Valu e > 
15 </PricingD e ta il > 

</Quot e Pric i ngD e ta i l> 
c/xc l :tomp l ato> 

- <xsl:tomp l at e match="cb l :Ba 6e ltemD e tai l "> 

<xsl:oal l- tomplato namo a 'CopyL i no l tomNum" /> 
20 <xGl:cal l- tomplato namo = "Copyltomldont i f i or 6 " /> 

<xGl:cal l- tomp l ato namo = "CopyTota l Quant i ty" /> 
</xs l :temp l at e > 
■ <xo l :tomp l ato namo="OutputQuot e Curroncy ,, > 

■ <xc l : i f toct = "cb l :RoquostQuotoCurroncy/cb l :Curroncy/ 
25 cb l :Curr e ncyCod e d"> 

■ <Quot e Curr e ncy> 

<xs l :copy - of so l oct = "cbkRoquostQuotoCurroncy/ obhCurronoy 11 /> 
</QuotQCurr e ncy> 
</xs l :if> 
30 </xs l :t e mplat e > 

- <xG l :tomp l ato namo= ,l OutputQuoteT o rmsOfPayment"> 
- <xsl:if tost= "cb l :RoquostQuotoTorm G OfPaymont'> 

- <Quot e TormsOfPaym e nt> 
■ <Paymont l nstructions> 
35 <xc l :ca ll template) namo = "OutputQuot o PaymontT e rm 8 " /> 

<xG l :Ga l l - tomp l ato namo="OutputQuotoPaymontM e thod" /> 
</Paymontlnstructions> 
</Quot e TormsOfPaym e nt> 
</xs l :if> 
40 </xG l :tomplato> 

- <xcl:tomplato nam e ="OutputQuotoPaym e ntT e rm 6 "> 

■ <xG l :for -e ach 

Go l oGt="cb l :R e qu es tQuot e Torm s OfPaym e nt/cbl:Paym e nt l n s truct i on s / 
cb l : PaymentTerm 6 "> 

45 - <Paym e ntT e rms> 

- <xGl:for - oach s e l e ct g 'cbhPaymontT e rmV 
■ <PaymontTerm> 

<xc l :copy - of so l oct = , 'cbl:PaymontTermCoded n /> 
<xG l :copy - of Go l oct = "cb l :PaymontTormCododOthor 11 /> 
50 <xcl:copy - of Go l oct=' t cb l :PaymentTormVa l uo" /> 
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<xs l :oopy - of so l oct = "cb l :Paym e ntT e rmD e ta il s" /> 
</PaymontTerm> 
</xs l :for - each> 
</PaymontT e rms> 
5 </xs l :for -e ach> 
</xsl:tomp l at e > 

■ cxohtomp l ato namo="OutputQuotoPaymontMothod"> 

- <xs l :for - oach soloct= "cbhRoquo s tQuotoTermsOf Paym e nt/ 

cb l :Paymont l n s truction s /cb l :PaymontM e thod"> 

10 - <PaymontM 8 thod> 

<xol:copy - of 6G l oct = "cb l :PaymontMoanCod e d" /> 
<xsl:oopy - of 6 el oct = "cb l :Paym e ntMeanCodedOth e r 11 /> 
<xcl:copy - of so l oct = "cbl:Paym e ntM e anRofer e nce" /> 
cxo l xopy of so l oct = "cbl:PaymontSy s tomCod e d" /> 

15 <xG l :copy - of so l oct="cb l :Paym e ntSy 6 t e mCododOth e r" /> 

<xs l :copy - of go l oct = "cb l :Orig i nat i ngF I Account 11 /> 
<xs l :copy - of s el8 Ct = "cbl:R e oe i v i ngF I Aocount" /> 
<xsl:copy - of 6 el 6Ct = "cb l :Card l nfo 11 /> 
</Paym e ntMethod> 

20 </xsl:for -e ach> 
</xsl:tomp l at e > 

■ <xsl:tomplato match = "cb l :R e qu e stQuot e lD"> 

<xs l :ca l)- t e mplato nam e ^CopyR e f e r e no e " /> 
</xs l :temp l at e > 
25 - <xGl:tomplato match=' , cbl:RequostQuotoParty"> 

- <Ord e rParty> 

■ <Buy e rParty> 

<xs l :app l y - temp l atos se le ot = "ob l :Ord e rParty/ 
cb l :BuyorParty/cb l : Party" /> 
30 </Buy e rParty> 

■ <So lle rParty> 

<xo l :app l y tomp l atos so l oct = "cbl:OrdorParty/ 
cb l :S elle rParty/cb l :Party" /> 
</Sell e rParty> 
35 </OrdorParty> 
</xs l :t e mplat e > 

- <xs l :tomp l ato match="cb l :Party"> 

<xo l :cal l- tomplate namo = "CopyParty" /> 
</xs l :tomplat e > 
40 </xG l :GtyleGh ee t> 

Party gopv.xsI 

■ <xc l :Gty l oGho e t vors i on = "1 .0" 
45 xmlnG:xslg"http://www-w3.org/1990/XSL/Tran6form n 

xmlnG:oxt="httpi/Avwwxommerceonoxom/xm l pr e6 M xmlnG:Gb l= "urn:x - 
comm e rc e on e : documont:com:commerceon e :XCBL30:XCBL30.sox$1 .0" 
xmln 6 :xm = "http:/Avwwxomm e rc e on e xom/xcb l ma i lbox"> 

- <x6 l :tomplato nam e ="CopyParty"> 
50 ■ <Party> 
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<xc l :apply - tomplatos GO l oot-'cbkParty l P" /> 
<XG l :ca l l - tomplato namo="CopyNamoAddro s s" /> 
</Party> 
</xsl:temp l ate> 
5 ■ <xcl:tomp l ato match= ,< cb l :Party l D ,t > 
■ <Party l D> 

<xcl:app l y tomplatos Go l oct^'^bhldont i f i or" /> 
</Party l D> 
</xs l :t e mp l at e > 
10 ■ <xsl templat e nam e= "CopyNameAddr es6 "> 
<xs l :Gopy - of GO le ct= ,, cb l :Nam e Addr e ss" /> 
</xs l :temp l at e > 
</xcl:stylesh ee t> 

15 [0055] The user acts upon the form 14 1 . Fields are added, completed or changed. 
More than one iteration may be required, for instance, if a user adds a line item to a 
quotation. When the user is ready, the form is posted to the server for validation. 
One or more types of validation can be applied, such as field validation against a 
schema (e.g., for well-formedness and valid ranges) and business processing 

20 validation against a rule base. For instance, a SOX-compliant xCBL schema and a set 
of Schematron rules can be used for validation. In Figure 12, the flow branches from 
141 depending on whether field validation is error free. An error free field validation 
is displayed 1224 with a message. A document containing field errors results in 
generation of an error document that is merged for display with the original document 

25 by a declarative transformation 1212, thereby displaying validation errors in the same 
user interface as the document being edited 1213. The user's actions may be iterative, 
to correct one or more errors before repeating field validation. The user may be 
presented 1225 with further options of validating the document against business 
processing rules applicable to one or more trading partners or of saving the document 

30 as a draft 1233. Alternatively, the multiple types of validations may be performed on 
the same document, without repeated user requests for validation. In one 
embodiment, business processing rules are applied by a Schematron engine 1232. 
[0056] Excerpts from a sample of a user form 141 that produced the sample 
screen in Figure 13 feUow fare reflected in the file "JSP CODE .txt" on the 

35 accompanying CD-ROM of the sou rce code. 

<] start Mailbox20.jsp > 

<HTML> 
40 <HEAD> 
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cT I TLEsxCBL Ma il box 2.0</T I TLE> 

<LINK hrof='../css/ma i n.css' ro l= STYLESHEET typo=toxt/css> 
</HEAD> 

S <BODY bgCo l or=#ffffff loftMarg i n=0 r i ghtMargin = 0 topMarg i n=0 
MARGINW I DTH-"0"MARGINHE I GHT-"0"> 

<ccr i pt l anguago="javaccr i pt" orc="../waiting.js"> 
</script> 

10 <ccr i pt l anguago="javaocr i pt" src="../d i oplayho l p.js"> 
</ s cr i pt> 

<j start l ogo.jsp > 

15 <TABLE bordor=0 collPadd i ng=0 oo l lSpac i ng=0 width="1 00%"> 
<TR> 

— <TD c l ass=nav i gat i on oo l Span=3 ho i ght=2>< I MG ho i ght=1 
— src = '../ i mg/spac e r.g i f' w i dth=1 > </TD></TR> 

I l l «»' 

20 — cTD w i dth = "27%"> < I MG hoight = 52 src = "../img/hloft l ogo.g i f"> </TD> 
— cTD noWrap width=" - 15%"> 

</scr i pt> 

25 «! ond l ogo.jsp > 

cTABLE bordor^O col l Padd i ng = 0 co ll Spac i ng=0 width = "100%"> 
— <TR class = topo ell > 

<TD ho i ght=18> < I MG ho i ght=1 src='../ i mg/spacor.gif w i dth = 1> </TD> 

30 cTD ho i ght^l 8 al i gn = "r i ght" class="HomoLink"> 

cA hrof = "XMSorvlot?wobaction =l n i t" c l asc = "HomoLink"> 

xCBL Ma il box</A>   </TD> </TR> 

</TABLE> 

cTABLE a li gn-contor bordor = 0 co ll Padding = 2 w i dth = "100%"> <TBODY> 
35 — «T-R> 

cTD a li gn=m i dd l o bgCo l or = #o9ocof vA li gn=top width = "20%"> 

«! start le ft_nav.jsp > 

40 cTABLE bordor=0 collPadding=2 collSpacing=0 width="00%% cTBODYj. 
<TR> 

— cTD al i gn=m i ddlo bgCo l or = tf000000> 

— cTABLE bordor=0 co li Padding=0 co l lSpac i ng = 0 w i dth="100%" 
o l acs = "LoftNav"> 

45 <sTR> 

cTD co l Span=2> <IMG bordor=0 ho i ght=3 src = '../img/cpacor.g i f 

width = 1> c/TD></rR> 
<sT-R> 

<TD a l ign=midd l o> </TD> 

50 <TD a l ign= l oft olacc="Bo l dToxt"> 
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<A 

hrof='XMSorv l ot?wobaot i on = FdrActionGotDooL i ct&Fo l dor_go_fo l dor=1'> 
V i ow Inbox </A> </TD></TR> 

*** 



<TD co l Span=2>< I MG bordor=0 ho i ght=3 src-'../img/cpacor.gif 

w i dth=1></TD> </TR> 
10 — 

<! ctart foldor_ i ndox.jop ■ > 

cFORM mothod^-"POST" namo='fo l dor_ i nd e x' 
aotion = 'XMS e rv l ot?wobaot i on al n i t'> 
15 <TR> 

— <TD a li gn-loft vA l ign=bottom>&nbcp;</TD> 
<TD al i gn = loft c l aoo="Bo l dToxt"> 

<A hr e f = "XMS e rv le t?wobaction = FdrAct i onShowMgmt"> 

20 Foldorc</A> </TD> </TR> 

*** 



25 </TD> </TR> </TABLE> </TD> </TR> 

<TR> 

— <TD a li gn=loft vA li gn=bottom> </TD> 
— <TD vAl i gn=top> 

30 ctablo co ll padd i ng=0 co ll epacing=0 bordor=0 clacc = "LoftNav"> 

<TR> 

cTD clacs="Smal l Toxt">     

<A 

35 hrof = "XMSoiv l ot?wobaction = FdrActionGotDocList&Foldor_goJoldor=11%RoH 
oyc e </A> 



cfTD> </TR> </TABLE> </TD> </TR> 

40 

c I NPUT namo-'Foldor^ro l oad' typo^h i ddon valuo="FALSE" ></ I NPUT> 
dNPUT namo-'foldor^omptyjrash' typo = h i ddon va l uo = "FALSE" ></ I NPUT> 
< I NPUT nam e =1old e rj3rovious_act i orV typo = hiddon 
va l uo = 'unknown'></ I NPUT> 
45 < I NPUT namo^Foldor^currontJoldor' typo=h i ddon valuo=T></ I NPUT> 
< I NPUT namo^'Foldor^goJo l dor 1 typo = h i ddon valuo=T></ I NPUT> 
</FORM> 

<J ond fold e rjndex.jsp > 

50 <scr i pt languago = "JavaScr i pt"> 
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5 



20 



funct i on e mptyTra s h() { 

i f(conf i rm('Empty trash?')) { 
documont.fo l dor_inclox.fo l dor_ompty_trash.va l uo = "TRUE"; 

documont.foldor_indox.action=''XMSorvlot?wobaction = FdrAct i onEmptyTrash"; 

documont.fo l doundox Fo l dor_goJoldor.va l uo - "4"; 

documont.fo l dor_indox.oubm i t(); 



10 } 
tt-> 



</script> 



-<T-R> 



15 <TD co l Span=2> <IMG bordor-0 ho i ght=3 src='../img/opacor.g i f' 

w i dth = 1></TD> </TR> 
— </TABLE> <fTD> </TR> 
</TABLE> 

<! e nd le ft_nav.jsp > 



</TD> 



<TD class=D i splayAroa vA l ign=top w i dth="80%"> 

25 <! Bog i n MA I N CONTENT CELL ■■ > 



cFORM ACTION-"XMSorvlot?wobact i on=XMPrintAct i on" namo = "pr i ntdoc" 
METHOD="poct" targot="_blank"> 
30 <input typo="hiddon" namo="Docid" 

va l uo="XVoETjJ6Y7 l vTgK i MgDgZU0jgWzcmOux4pThkFH0oPQ="> 

</FORM> 

c! Bog i n FORM ■- > 
35 <FORM ACT I ON="XMSorv l ot" namo = "mainform" METHOD="post"> 

dnput typo="Hiddon" namo="BackTypo" va l uo ="1"> 

< i nput typo="Hiddon" namo = "Fo l dor_roquostod_pago" va l uo="2"> 

40 dnput typo = "H i ddon" namo="Foldor_go_fo l dor" va l uo="1"> 

< i nput typo^'H i ddon" namo = "Doc li 6t.oort_by" va l uo="1D"> 



<input typo="H i ddon" nam 8= "BaokToDooumont" valu e - 
<soript language = "JavaScr i pt"> 
45 cloco Wa i ting W i ndow('procoss'); 



II -4 II 



function doXPostProc e ss(wQbaot i on, xpost, xpath, va l ) 



— docum e nt.ma i nform.w e baction.va l uo = wobact i on; 
50 — var fi el dNam e = xpost + xpath; 
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— dooumont.mainform[fio l dNamo].va l uo = val; 
— dooumont.mainform.subm i t(); 

} 

5 function doRomovo l tQmLovo l Attaohmont(wobaot i on, xpost, xpath, va l , attachur i ) 

{ 

— docum e nt.mainform.wobact i on.valuo = wobaction; 
— var f iel dNamo = xpost i xpath; 
— docum e nt.ma i nform[fio l dNam e ].va l uo - val; 
10 — dooumont.ma i nform.AttUr i .va l uo-attachur i ; 
— dooumont.ma i nform.submitQ; 

} 

funct i on doR e movoLin el tem(webact i on > xpost, xpath, va l , l in e item) 
15 { 

— docum e nt.mainform.wobaction.valuo = wobaction; 
— var f i oldNamo = xpost i xpath; 
— docum e nt.mainform[fieldNam e ].valu e = val; 
— docum e nt.mainform.Remov e Lino l t e m.value =l in e it e m; 
20 — docum e nt.mainform.submitQ; 

} 

funct i on doXPostProcossWithDofault(wobact i on, xpost, xpath, va l , 
dofJio l dNam e , def_va l ) 
25 {— 

— documont.ma i nform.wobaction.va l uo = w e baction; 
— var f i oldNamo = xpost i xpath; 
— documont,ma i nform[f i oldName].va l uo = val; 
— var DTnow = now Dat e (); 
30 — documont.mainform[dof _fio l dNamo].va l uo = doLval i ":" i DTnow.gotTimo(); 
— document.ma i nform.subm i tO; 

} 

var i cMod i fiod = fa l s e ; 
35 funct i on cotMod i fiod(xpost) { 
— i sMod i f ie d = true; 

— document.mainform[xpost].valu e = 'tru e 1 ; 
} 

40 funct i on addNowAttachmont(wobact i on, attachmontUR I , xpath^val) { 
— docum e nt.ma i nform.wobact i on.va l u e= w e bact i on; 
— docum e nt.ma i nform.doc l ov el att.va l u e = "1"; 

— attachmontUR I J I d = ova l ("documont.mainform." i "XMAttachmontUr i "); 
— attachmontUR I Jld.valuo = attachmontUR I ; 
45 — f i loNamoXPathJ I d = ova l C'documont.mainform." i "F i loNamoXPath"); 
— f i loNamoXPathJ I d.va l uo = xpath_va l ; 

} 



50 funct i on backToDocList() 
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— if (dooum e nt.ma i nform.BaokTypo.va l uo -- "1") 

documont.ma i nform.act i on = "XMSorv l ot?wobaction=FdrActionGotDocList"; 

— oloo i f (documont.mainform.BackTypo.va l uo == "2") 

5 documont.mainform.act i on - "XMSorv l ot?wobact i on = XMSoarchDoc"; 

— etee 

docum e nt.mainform.act i on - 

"XMSorvlot?wobact i on=FdrAct i onRopl i odDoc"; 
— documont.mainform.submit(); 
10 } 



function e d i tNot es () 
{ 

15 — i f (isMod i f i ed) 
— I 

if (!conf i rm('You havo not oavo your changos, oont i nuo? ')) 

r e turn; 

— } 

20 — documont.ma i nform.wobaotion.va l uo="RREd i tNotosAction"; 
— docum e nt.ma i nf orm ,subm i t() ; 

} 

function oditAttaohm e nt() 

25 { 

— documont.mainform.wobaction.valuo="CRAttachAct i on"; 
— documont.mainform.doclovo l att.valuo - "0"; 
— documont.ma i nform.subm i tO; 

} 

30 U—> 
</scr i pt> 

gtab l o width="1 00%" bordor="0" co ll cpacing="0" co ll padding-"1"> 
<tr clacs = "Hoader"> 
35 <td olaoG="HoadorToxt" a li gn=" l oft"> Draft </td> 

<td olaoo="HoadorToxt" al i gn="r i ght"> <a hrof-"" 
onc l ick="javaccr i pt:backToDocL i st(); roturn falso;"> Back to l i st of 
documonto </a> &nbop;&nbop; </td> 

40 

</tabl e > 

< i mg oro = "../img/cpaoor.g i f" a l H"" hoight = "5" w i dth = "1"><br> 

45 < i nput typo="hiddon" namo="wobaction" va l uo=""> 

c i nput typo="h i ddon" namo-"doo l ovo l att" va l uo="0"> 

< i nput typo = "hiddon" namo="XPootDooumont l D" 

valuo="XVoETjJ6Y7 l vTgK i MgDgZU0jgWzcmOux'1pThkFH0oPQ = "> 

<input typo="h i ddon" namo="Doc i d" 
50 valuo="XVoETjJ6Y7lvTgK i MgDgZU0jgWzcmOux'1pThkFH0oPQ="> 
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c i nput typo="h i ddon" namo="XMAttachmontUr i " va l uo-""> 
cinput typo-"hiddon" namo="AttUr i " valuo-""> 
cinput typo="h i ddon" nam e ="FiloNamoXPath" valuo=""> 
cinput typo="h i ddon" namo - "RomovoLino l tom" va l uo-""> 

5 

c! HEADER BAR ■■ > 

ctab l o w i dth="100%" bordor="0" co l lspae i ng^"0" co l lpadding="2"> 
<tr o l ass="H e ader"> 

10 — <td al i gn = "loft" w i dth = "30%" nowrap o l aos="HoadorToxt"> Rop l y 
To: Rubicon  </td> 
— <td a li gn="right" nowrap width="30%" clacc="E l omontSty l o"> 

c i nput typcWeubmit" namo="Sond" va l uo-"S e nd" c l ass = "E l omontStylo" 

onC li ok="dooumont.mainform.wobaot i on.va l uo='CRSondAot i on'; 

15 java c or i pt:oponWa i tingWindow('XMSoiv l ot?wobaot i on=XMD i op l ayProooGO i ng','pr 
OGOss');java6cr i pt:docum e nt.ma i nform.eubm i t(); return fal se ;"> 

c i nput typo = "oubmit" namo="Savo" va l uo="Savo as Draft" 

c l aco="E l omontSty l o" 

onC li Gk = "documont.ma i nform.wobaot i on.valuo='CRSavoAct i on'; 
20 javaccr i pt:oponWait i ngWindow('XMSorvlot?wobact i on=XMDisp l ayProcoos i ng','pr 
ocoss');javascr i pt:doGumont.ma i nform.subm i t(); return fa l se;"> 

< i nput typo="cubmit" nam o = "Va li date" va l uo="Va li dato" 

olaoo="E l omontSty l o" 

onC li Gk = "documont.ma i nform.w e bact i on.va l u e= 'CRVa li dat e AGtion'; 
25 javasGript:oponWa i tingW i ndow('XMSorvlot?wobact i on=XMDisp l ayProGOGG i ng','pr 
ocoso');javascript:docum e nt.mainform.subm i t(); roturn false;"> 

c i nput typo="rocot" namo="Rosot" va l uo="Rooot" class = "ElomontSty l o"> 

</td> 

30 c/tab l o> 

ctab l o width="100%" bordor = "0" co ll Gpae i ng = "0" oo l lpadding="2"> 
ctr c l acG = "Hoad e r"> 

— ctd al i gn = "loft" nowrap c l acs = "HoadorToxt">Quoto</td> 
35 — ctd al i gn="r i ght" nowrap c l aoo="HoadorToxt"> 

— ca hrof="" onc li ck- "javaocr i pt:oditNotOG(); roturn fa l s e " 

onMousoOv e r="status = 'Ed i t docum e nt notos'; r e turn truo;" 

onMousoOut="status="; roturn fa l s e ;"> 

— < i mg src = "../img/icon_notoG.g i f" width-"15" hoight="15" 
40 bordor = "0"> </a> &nbsp 



ca hrof="" onc li ck="documont.pr i ntdoc.Gubm i t(); roturn falso" 
onMouooQvor="status - 'Pr i nt documont'; roturn truo;" onMousoOut="status="; 

45 roturn fa l se;"> 

c i mg crc="../ i mg/ i con_pr i nt.g i f" width = "15" hoight="15" 

bordor="0"> </a>&nbcp;&nbsp 
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— <a hrof="" oncl i Gk="javaocript:oditAttachmont(); roturn fa l so;"> Add/Edit 
Attaohmonts</a></td> 

</tabl e > 

5 

dmg src = "../ i mg/spaoer.g i f" a l t="" hoight="3" w i dth="1"/xbr/> 
<tab l o w i dth="100%" bordor="0" oo l lcpac i ng="0" eol l padd i ng="0"> 



10 <4f> 

<! — MA I N documont ar e a --> 
ctd oo l span="2"> 
<Fram e > 

<?xm l vorsion^'l .0" oncod i ng="UTF - 8"?> 
15 <TABLE xmlns:cbl="urn:x - 

comm e rc e on e :docurn e nt:com:cornmorc e on e :XCBL30:XCBL30.sox$1.0'' 

xm l nc:xm=''http://www.commorcoono.com/xcb l mai l box'' 

xmlnc:oxt=''http://vvww.commorcoono.com/xm l pros" width = "1 00%" bordor="0" 

oo l lopao i ng="0" co l lpadd i ng="1 "><TR o l ass^"ListHoador"> <TD 
20 c l acs^ListHoadorToxt" co l cpan="2" a li gn = " l oft">Quoto 

Hoador: <JTD> </TR> <TR> <TD w i dth="50%" 

c l aeo = "StatusH e ad e rSma l lN e w"><span 

c l acc = "Roqu i rodFiold">*</cpan>Quototf:</TD? <TD w i dth="50%" 

class = "StatusHead e rSma l lNow"><span c l ass="Roqu i rodF ie ld">*</spar»Quot e 
25 I ssu e Dat e : 

— (Pl e as e Input as MM/dd/yyyy) 

— </TD> </TR> <TR> <TD w i dth="50%" clasc="E l omontStylo"> <input valu e = n " 
namo = "XPootChango:/Quoto/QuotoHoador/QuotolD/Roforonco/RofNum" 

typo = "h i ddon"/> <input 
30 onChango="javascript:cotModif i od('XPostChango:/Quoto/QuotoHoador/QuotolD/ 

Roforonco/RofNum');" c i zo = "20" va l uo="PC - 00 9 " 
namo = "XPostContont:/Quoto/QuotoHoador/Quoto l D/Roforonco/RofNum" 

typo = "toxt" class^-E l omontStylo"^ </TD> <TD width="50%" 
c l aes = "Elom e ntSty l e"x i nput va l u e= "" 
35 namo = "XPoctChango:/Quoto/QuotoHoador/QuotolccuoDato" 

typo = "hiddon"/> <input 

onChango="javasGript:sotMod i f i od('XPostChango:/Quoto/QuotoHoador/Quoto l ss 
uoDato');" cizo="15" va l uo="" 

namo="XPoctContont:/Quoto/QuotoHoador/QuotolssuoDato" typo="toxt" 
40 c l acs="E l omontSty l o"/> </TDx/T"R> <TR o l ass="L i otRowA l tornato"> <TD 

c l acc="StatusHoadorNow" width = "50%" a l ign=" l oft"> Quoto Sont to BuyonABB - 
1010c/TD> <TD o l aoo = "StatusHoadorNow" width="50%" al i gn = " l oft"> From 
SollonABB 1010</TD> </TR> <TRxTD o l aoo="BodyToxt">ABB Cornorstono 
Company </TDxTD olass="BodyToxt"> ABB Cornorstono 
45 Company </TD> </TRxTR> <TD o l acs="BodyToxt"> 15 Torranco B l vd.</TDxTD 
c l acc = "BodyToxt">15 Torranco Blvd.</TD> </TR? <TR> <TD 
olaoc = "BodyToxt">7th F l oor</TD> <TD class="BodyToxt">7th 
F l oor </TD> </TR> <TRxTD c l acs="BodyToxt"> Auct i on Dopartmont</TDxTD 
olaes="BodyT e xt"> Auction Dopartm e nt</TDx/TR> <TRxTD 
50 clacs = "BodyToxt"> Angolv ill o, 
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USCA06660</TD> <TD c l ass="BodyToxt"> Ango l vil l e, 
USCA06660</TDx/TR> <TR> <TD o l ass="BodyToxt"> US </TD> <TD 
c l aoc="BodyToxt">US</rD> </TR> c i mg w i dth-"1" ho i ght="5" alW" 
orc = "../ i mg/spacor.gif"/> <BR/> </TABLE> <TABLE xm l nc:cb l ="urn:x - 
5 commoroeono:documont:com:commorcoono:XCBL30:XCBL30.sox$1.0" 
xm l ns:xm = "http://www.commorcoon e .com/xcblmai l box" 
xm l nG:oxt="http://www.commorcoono.com/xmlpros" width="1 00%" bordor="0" 
col l opac i ng = "0" co l lpadding = "0"> <a 

namo = "QuotoDotai l _Lino l tomLabo l now"/> cTR class="LiotHoador"> <TD 

10 c l aoc = "L i stHoadorToxt" a li gn = " l oft">Quoto Dotai l :</TDxTD 
Glacc="L i ctHoadorToxt" a li gn="r i ght" co l span='M"> <input va l uo-"" 
namo="XPoctAdd l nto:/Quoto/L i ctOfQuotoDota il s" typo = "h i ddon"/xa 
onMousoOut = "status = "; r e turn fa l se; onMous e Ov e r = "status = 'Add N e w L i n e 
I tom'; roturn truo;" onCl i ok="doXPostProooss('CRSavoAot i on', 'XPootAdd l nto:', 

15 '/Quoto/ListOfQuotoDota il c', 'QuotoDotailo'); roturn fa l so;" 

hrof = "ffQuotoDotaiLL i no l tomLabo l now">[Add L i ne ltom]</ax/TD> </TR> <TR 
bgoolor="ffOOOOOO"xTD ho i ght="1" colopan="5"> c i mg width="1" hoight="1" 
a l t = "" crc="../ i mg/spaoor.gif"/> <fTD> c/TR> cTR> <TD ho i ght="3" 
colcpan="5"> c i mg w i dth="1 " ho i ght="3" a l t="" 

20 crc = "../img/spacor.g i f"/> <fTD> </TR> <TR c l ass^"L i stRow3"> <TD 

clacc="StatucHoadorSma ll Now" align="loft">Quoto Itom Dotai l 1 </TDxTD 
claco = "L i stRowA l tornatoToxt" a l ign = "right" oolspan = "4"> <input va l uo="" 
namo = "XPostRomovo:/Quoto/L i GtOfQuotoDotailc/QuotoDota i lo[1]" 
typo = "h i dden"/xa onMousoOut="status = "; r e turn fa lse ;" 

25 onMous e Ovor = "status = ' Remov e L i n e I t e m'; return tru e ," 

onC li ck="doRomovoL i no l tom('CRRomovoL i no l tomAct i on', 'XPoctRomovo:', 
'/Quoto/L i otOfQuotoDota i ls/QuotoDota il s[1]', 'truo', 'Lino l toml'); roturn falco;" 
hrof = "frQuotoDetai l _L i ne l temLab e ln e w">[Romov e L i ne 
ltom]c/a> c/TD> </TR> <TR> <TD c l ass="StatucHoadorSmallNow" co l spang"5" 

30 a l ign=" l oft"> cGpan class="Roqu i rodF i old">*</span>Quoto 

Typoc/TD> </TRxTR> <TD o l ass="E l omontSty l o" oolcpan="5" al i gn=" l oft"> < i nput 
valuo="" 

namo="XPostChango:/Quoto/L i otOfQuotoDotai l o/QuotoDotai l s[1]/QuotoltomTypo 

/QuotoTypo/QuotoTypoCodod" typo="hiddon"/> cSELECT 

35 onChango="javaccr i pt:cotMod i fiod('XPoctChango:/Quoto/L i stOfQuotoDotai l s/Quo 
toDotai l c[1 ]/QuotoltomTypo/QuotoTypo/QuotoTypoCodod');" ho i ght="1 0" 
namo="XPootContont:/Quoto/L i stOfQuotoDota i ls/QuotoDotails[1]/QuotoltomTypo 
/QuotoTypo/QuotoTypoCodod"> cOPT I ON VALUE = SELECTED > 
cOPT I ON VALUE=Aooopt > Acc e pt 

40 cOPT I ON VALUE = AccoptW i thChangos > Accopt W i th Changoc 
cOPT I ON VALUE-A l tornatoBid > A l tornato Bid 
cOPT I ON VALUE-BoctAndFina l > Bost And F i nal 
cOFT I ON VALUE-iBidW i thoutExoopt i on > B i d W i thout Exception 
cOPT I ON VALUE-Othor > Custom Codo 

45 cOPT I ON VALUE=Doc l ino > Doclin e 

cOPT I ON VALUE-iDoc l inodToQuoto > Doc li nod To Quoto 

cOPT I ON VALUE = RoquostForTimoExtons i on > Roquost For Timo Extons i on 

cOPT I ON VALUE=Unab l oToQuoto > Unab l o To Quote 

c/SELECT> c/TD> </TR> <TRxTD c l ass="StatucHoaderSma l lNow" 

50 val i gn="bottom" align=" l oft"> <span 
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olace="RoquirodF i o l d">*</epan> ltom</TD> <TD c l acs = "StatucHoadorSmal l Now" 
va li giW'bottom" al i gn = " l ott">Part#</TD> <TD olaoo="StatuoHoadorSma l lNow" 
width="30%" va l ign = "bottom" a li gn=" l oft"> Doccription </TD> <TD 
olaoo="StatuoHoadorSma ll Now" va li g i W'bottom" al i gn=" l oft"> Qty </TD> <TD 
5 o l aoo="StatuoHoadorSmal l Now" va l igiW'bottom" 

a l ign = " l oft">U/M</TD> </TR><TR> <TD c l ass-="BodyToxt" va l ign="top" 
a l ign = "loft"> <input valu e ="" 

namo = "XPostChango:/Quoto/L i ctOfQuotoDota il c/QuotoDotailc[1]/Quot el tomDota 

il /LinoltomNum/BuyorLino l tomNum" typo="h i ddon"/> < i nput 
10 onChango = "javascript:cotMod i f i od('XPoctChango:/Quoto/LictOfQuotoDota i ls/Quo 
toDota i lc[1]/Quoto l tomDota il /L i no l tomNum/BuyorL i no l tomNum');" 
maxlongth = "11" sizo = "5" va l uo="1" 

namo="XPostContont:/Quoto/LictOfQuotoDota il s/QuotoDota i ls[1]/Quot el tGmDota 
il /Lino l tomNum/BuyorLino l tomNum" typo = "toxt"/x/TD> <TD olacs=-"BodyToxt" 

15 va li grW'top" al i grW l oft">T 77 0 0 - 66</rD> <TD c l aoG = "BodyToxt" va li grW'top" 
aligrW' l oft" w i dthr-"30%"/> <TD c l aoo="BodyToxt" val i grW'top" 
align=" l oft"> 6000000.00 c/TD> <TD claGG = "BodyToxt" va l igW'top" 
al i gn=" l oft">EA</TD> </TR> <TR class="ListRowA l tornato"><TD 
o l aos="StatusHoadorSma l lNow" oo l oparW'5" a l ign=" l oft">To Bo Comp l otod by 

20 Offoror: </TD> </TRxTR olaeo="LietRowAltornato"> <TD Golcpan="5"><TABLE 
bordoWO" co ll padd i ng="0" oo l lGpac i ng="1" w i dth="100%"> <TR> <TD 
c l aGG = "StatuoHoadorSma ll Now" va li giW'bottom" al i gn = " l oft"> <span 
o l aoo="RoquirodF i old">*</epan>Unit Prico:</TD> <TD 
c l aGG="StatuGHoadorSma ll Now" va li giW'bottom" a li gn = "loft"> <span 

25 c l aGS = "RoquirodFio l d"> * </opan> U/M: </TD> <TD o l acG = "Stati i GHoadorSmallNow" 
va li gn="bottom" a li gn = " l oft"> <cpan c l aGG = "Roqu i rodF i o l d">*</Gpan>Tota l 
Pr i co: </TD> </TR> <TR> <TD valign="top" a li gn=" l oft"> <input va l uo="" 
namo = "XPoGtChango:/Quoto/LiGtOfQuotoDotai l G/QuotoDotai l G[1]/QuotoPriGingD 
ota i l/Pric i ngDotai l /LiGtOfPr i co/Pr i co[1]/UnitPr i co/Un i tPr i coVa l uo" 

30 typo="hiddon"/> < i nput 

onChango="javaGcript:60tModif i od('XPoGtChango:/Quoto/LiGtOfQuotoDotai l s/Quo 
toDotailG[1]/QuotoPr i c i ngDota il /Pric i ngDota i l/LiGtOfPr i co/Pr i co[1]/UnitPriGo/Un i tPr i 

ooVa l uo');" max l ongth="28" s i zo="16" va l uo="" 

namo = "XPoGtContont:/Quoto/LiGtOfQuotoDota il c/QuotoDota il G[1]/QuotoPr i c i ngD 
35 ota il /Pr i c i ngDota i l/LiGtOfPr i co/Prico[1]/Un i tPriGo/Un i tPr i GoValuo" typo = "toxt" 
olacG="ElomontSty l o"/x/TD> <TD val i grW'top" al i gn = " l oft"x i nput va l u e -"" 
namo = "XPoGtChango:/Quoto/LiGtOfQuotoDota il e/QuotoDota i lG[1]/QuotoPr i c i ngD 
otai l /Pr i c i ngDota i l/LiGtOfPr i co/Prico[1]/UnitPr i Go/Un i tOfMoaGuromont/UOMCodQd 

" typo="h i ddon7> <S ELECT 
40 onChangQ="javaoGr i pt:GOtModifiod('XPoGtChango:/Quoto/L i GtOfQuotoDota il G/Quo 
toDota i lG[1]/Quot Q Pr i G i ngDGtai l /PricingDotai l /L i GtOfPr i co/Prico[1]/UnitPrico/UnitOf 
Moasuromont/UOMCodod');" ho i ght="1 0" 

namo="XPoGtContont:/Quoto/LiGtOfQuotoDotai l G/QuotoDota i lG[1]/QuotoPr i c i ngD 

ota il /PriGingDota il /LictOfPr i co/Pr i co[1]/Un i tPrico/UnitOfMoasuromont/UOMCod e d 
45 "> ^OPT I ON VALUE= SELECTED > 

cOPT I OM VALUE-FC > 1000 Cubic Feet 

^OPT I ON VALUE-MQ > 1000MotorG 

cOPTIOM VALUE=KS > 1000 Poundo Por Squaro I nch 

<OPTION VALUE-BP > 100 Board Foot 
50 cOPT I ON VALUE = KK > lOOK il ogramc 
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cOPTION VALUE = YL > 100 Linoa l Yards 

★** 



5 cOPT I ON VALUE=B22 > K il oamporo 

cOPT I ON VALUE = TAH > K il oampor e Hour Or Thousand Amporo Hour 

cOPTION VALUE=B21 > K il oamporo Por Motro 

cOPT I ON VALUE=B23 > K i loampore Por Squaro Motro 

cOPT I ON VALUE=KBA > Ki l obar 
10 cOPT I ON VALUE = 2Q > K il obocquorol 

cOPT I ON VALUE-B25 > K il obocquoro l Por K i logram 

cOPT I ON VALUE-2P > K il obyte 

cOPT I ON VALUE-KB > K il ooharactor 

cOPT I ON VALUE=B26 > K il ocou l omb 
15 cOPT I ON VALUE=B27 > K il ocou l omb Por Cub i c Motro 

cOPT I ON VALUE=B28 > K il ocou l omb Por Square M e tre 

cOPT I ON VALUE-2R > K i locur ie 

cOPTION VALUE=B20 > Ki l oo l octronvo l t 

cOPT I ON VALUE=78 > K il ogauss 
20 cOPT I ON VALUE=KGM > Kilogram 

*** 



cOPT I ON VALUE=WG > W i no Gal l on 
25 cOPT I ON VALUE = WM > Work i ng Month 
cOPT I ON VALUE-WR > Wrap 
cOPT I ON VALUE-YRD > Yard 
cOPT I ON VALUE-ANN > Years 

c/SELECT? c/TD> <TD valign="top" a li gn=" l oft"> c i nput va l uo^"" 
30 namo="XPoGtChango:/Quoto/L i ctOfQuotoDota il s/QuotoDota i lo[1]/QuotoPrio i ngD 
ota il /PricingDota il /Tota l Va l uo/MonotaryVa l uo/MonotaryAmount" 
typo = "h i dd e n"/x i nput 

onChango-"javascr i pt:cotModifiod('XPostChango:/Quoto/L i stOfQuotoDotai l s/Quo 
toDotai l s[1]/QuotoPricingDotail/PricingD e tail/Tota l Va l uo/MonotaryValuo/Monetar 

35 yAmounf);" max l ongth="28" oizo = "15" valuo=" n 

namo = "XPostContont:/Quoto/L i ctOfQuotoDotai l c/QuotoDota il s[1]/QuotoPric i ngD 

otai l /Pr i c i ngDetai l /TotalVa l uo/MonotaryVa l uo/MonetaryAmount" typo = "toxt" 

c l acs = "ElomontSty l o"/> </TD> </TR> </TABLE> c/TD> > ^TR> <TR 

c l acs = "L i ctRowA l tornato"> <TD c l ass="StatucHoadorSma ll Now" 

40 align=" l oft">Attachmont: c/TD> cTD co l cpan="1" o l aGS="L i stRowA l tornatoToxt" 

a l ign = "right"> <input va l u e ="" 

namo="XPostDofau l tVa l uo:/Quoto/L i stOfQuotoDotai l s/QuotoDota il s[1]/Quoto l tem 
LiotOfAttachmont/ListOfAttachmont/Attachmont[1]/AttachmontLocat i on" 

typo = "h i ddon"/x i nput va l u e= "" 
45 namo="XPoctAdd l nto:/Quoto/LictOfQuotoDota il c/QuotoDota il s[1]" 

typo = "hiddon"/> t i nput 

onC li ck="javaccr i pt:doXPostProcossWithDofau l t('CRSavoAction', 

'XPoctAddlnto:', 7Quoto/L i stOfQuotoDota il c/QuotoDota i ls[1 ]', 

'Quoto Ito m ListOf Attach m ont' , 
50 'XPoctDofau l tVa l uo:/Quoto/ListOfQuotoDota i lc/QuotoDotai l c[1]/Quoto l tomL i stOfA 
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ttachmont/L i otOfAttachmont/Attaohmont[1]/AttachmontLooation', 
'urn:attaohmont1_1'); roturn fa l oo;" c l aes="ElomontSty l o1" 
namo = "AddAttachm e nt" valuo = "Add Attachment" 

typo = "cubm i t"/> <fTD> <fTR> <TR c l aoo="LiotRowA l tornato"> <TD ho i ght-"8" 
5 oo l opan="5"> <img width="1" ho i ght-"8" alt-"" 

crc = "../img/cpacor.g i f"/><yTD><yTR> cTR bgco l or="#000000"> <TD hoight=-"1" 
co l opan = "5"> < i mg w i dth = "1" ho i ght = "1" alt-"" 
orc="../img/spac e r.g i f"/x/TD> </TR> </TABLE> < i mg xmlno:ob l ="urn:x - 
Gommorcoon e :docum e nt:com:oommerGOono:XCBL30:XCBL30.sox$1.0" 
10 xmlns:xm="http://www.comm e rcoono.com/xcb l ma il box'' 

xm l nc:oxt="http://www.Gommorcoono.com/xmlpros" width = "1" ho i ght = "20" alt="" 
Grc = "../ i mg/Gpacor.g i f"/> <BR xm l nc:Gbl="urn:x - 

commorcoon e :document:com:Gommercoon e :XCBL30:XCBL30.sox$1.0" 

xmlns:xm="http://www.Gomm e rc e on e .com/xoblmailbox'' 
15 xmlno:oxt="http://wvvw.commorGOono.oom/xmlpros7><TABLE xm l ns:cbl="urn:x - 

Gommorcoon e :docum e nt:Gom:commorGoon e :XCBL30:XCBL30.sox$1.0" 

xm l ns:xm=''http://vvvvw.Gomm e rG e ono.Gom/xGb l ma il box" 

xm l nG:oxt="http://vvvvw.Gommorcoono.Gom/xm l pro6" w i dth = "100%" bordor="Q" 

eo l lGpacing = "0" co ll padding="0"><TR claoo="L i etHoador"> <TD 
20 G l acG="StatuGHoadorNow1 " al i gn=" l oft"> Quoto Summary: </TD> </TR> </TABLE> 

</Fram e > 

</td> 
</tf> 
25 </tab l o> 

<\ — END MA I N document aroa -■ > 

</FORM> 
30 c! END FORM ■■ > 

<i — END MA I N oontont co ll ■■ > 



35 <fTD> </TR> </TBODY> 

</TABLE> 
</BODY> 
</HTML> 

<! e nd Ma il box20.jsp > 

40 

[0057] Figure 13 is a sample user interface screen. This screen corresponds to the 
HTML code above. Alternative embodiments may use a display language other than 
HTML or may use smart terminals or thin clients instead of being specifically adapted 
45 to browsers. In figure 13, a number of user controls are provided. A send control 
1301 allows a user to send a completed document. Preferably, the document is 
validated prior to the send control being functional. A save as draft control 1302 
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allows the user to save the document without sending it or validating it. A validate 
control 1303 allows the user to invoke one or more levels of validation. Data entry 
validation may be supported for editable fields without invoking this validate control. 
For instance, numeric data may be required in the unit price field 1328 and the total 
5 price field 1331, even without invoking the validate control 1303. Controls for 

adding and removing line items 1304 are appropriate to a quote, request for quote or 
similar electronic commerce document. These controls may either invoke a procedure 
running within a browser, such as a JavaScript procedure, or may cause a client to 
contact a server for an updated screen. An add attachment control 1305 allows the 

10 user to add an attachment, which then is listed under attachments 1332. In this 
example, the fields of a quote can be grouped. The status of this example is draft 
1311. A reply to designee is identified 1312. The document type is a quote 1313. 
The quote header 1314 in this example includes a sequence number, which may be 
automatically generated by either the client or server, and a date field which may be 

15 automatically populated or manually entered. The issuer and recipient data 1315 is 
generated by a transformation of a request for quotation. The quote detail 1321 
includes several fields of various types. A status field populated from a pull down 
menu as provided 1322. An item number 1323 is given a starting value, which may 
be editable. Additional fields 1324-1327 copy into the quotation information from the 

20 request for quotation. The user completes the unit price 1328. A unit of measure is 
selected from a pull down menu 1329. This field could be given a starting value to 
match the request for quotation. A total price field 1331 can be completed by the user 
or automatically calculated as an extension of the quantity and unit price. A quote 
summary field 1333 can be generated automatically or filled in by a user. Not visible 

25 in the sample screen, but included in the HTML code above are path specifications 
corresponding to fields of data that appear on the screen. Path specifications may be 
provided for all fields or only for editable fields. Also not visible are update status 
fields. The HTML code above provides a hidden update status field for at least the 
editable fields. This optional update status field can be used by either the client or the 

30 server to process and update more efficiently. The client can use an update status 

field to limit the information communicated to the server, in some embodiments. The 
server can use the update status field to avoid changing values already resident in 
memory, in some embodiments. 
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[0058] Figure 14 is a sequence diagram for communications among components 
such as those depicted in the alternative embodiments of figures 6, 7 and 1 1. The 
browser 1401 is the component with which the user interacts. It may be a web 
browser, a thin client, a smart terminal or other equivalent hardware and software 
5 interface. The servlet 1402 runs on the server. The rule selector 1403 is a component 
for choosing the appropriate rules, forms etc. The transformation component applies 
a declarative transformation to a self-describing, structure document. For instance, an 
XSL style sheet can be applied to an XML document to generate a new XML 
document. Or, a JSP page or XSLT style sheet can be applied to an XML document 
10 to generate an HTML page for display. A variety of declarative transformations can 
be used. A database 1405 manages persistent storage. An XML engine 1406 
manipulates an XML document in memory. 

[0059] The sequence in figure 14 begins at the browser 1401, with a user viewing 
a request for quotation document 141 1. The user requests generation of a reply 

15 document 1412. The servlet initiates mapping the document to a set of potential 

replies 1413. The servlet may receive from the browser a starting document type or it 
may receive a document ID for a self-describing, structured document and learn the 
document type from accessing the document. From a starting document type, the rule 
selector is invoked 1414 to determine the available reply types. The transformation 

20 engine generates an interface screen 1415, which the servlet returns to the browser 

1416. The user selects a reply type, for instance a quote 1417. The servlet transforms 
the starting document, in this example a request for quotation, into a draft resulting 
document 1418, in this case a quote. In no particular order, a style sheet is retrieved 
1419 and applied to the quote to generate a user interface screen (implied), the quote 

25 is persisted by the database 1421 and, in some embodiments, the quote is loaded into 
an internal data structure for ease of manipulation 1421. This data structure may be a 
DOM tree. Once data for the user interface has been generated, it can be transmitted 
by the servlet to the browser 1422. The user updates fields and sends all or part of the 
data received from the servlet back 1423. The servlet may either have the draft quote 

30 in memory, it may retrieve the draft quote from the database 1424 and create a data 
structure in memory 1425 to be updated 1426, or it may create a quote from the data 
received back from the browser. In the embodiment illustrated here, the draft quote is 
retrieved from a database and updated 1426 with the fields that have been flagged as 
modified by the user. The updated data structure in memory is used to generate a 
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self-describing, structured document 1427, which is persisted to the database 1428. 
Once updating has been accomplished, the update is communicated to the browser 
1429. Not shown in this sequence are the validation steps previously discussed. 
[0060] Figure 15 depicts an action command framework. In this framework, the 
5 servlet translates actions into one or more commands. This facilitates modification of 
process flow and reuse of sub process steps. A number of software components 1501- 
1507 are used to implement this framework. The sequence diagram depicts 
initialization of the object factory 1511. A request container is created 1512. The 
requested action from a user is created using the initialized object factory and request 

10 container 1513. The object factory acts to create the requested action 1514, consistent 
with appropriate selection of parameters, forms, etc. The servlet directs execution of 
the action 1515. A set of commands are created to carry out the action 1516. The 
object factory creates the appropriate commands 1517. The commands are executed 
1518, and an appropriate JSP page accessed 1519. 

15 [0061] Figure 16 depicts interaction among the servlet, the XPost interpreter and 
the XML engine when receiving a request from the client. A set of software 
components 1601-1616 are provided. Prior to the sequence illustrated in this figure, 
the servlet 1601 receives data including sets of update operators, path specifications 
and update values. In one embodiment, the servlet receives this data from a client 

20 browser via an HTTP post command in an HTML format. The servlet passes the data 
161 1 to an iterator 1602. The iterator builds a dictionary, table or other data structure 
in a form that the interpreter expects 1612. The servlet 1601 invokes 1613 interpreter 
1603 to process the data structure. The interpreter exchanges messages 1614, 1615 
with access control to determine the security status of the requestor. Assuming that 

25 the security check passes, the interpreter instantiates 1616 the resources needed to 
process the data. Fields received from the user are unmasked 1617 from a user- 
friendly format to a canonical format used for internal processing. This un-masking is 
repeated as often as required 1618. With data in a canonical format, the XML engine 
1605 is invoked 1619 to update a document consistent with the data structure. The 

30 updated document is returned 1620, 1621. Some of the components involved in the 
sequence are depicted in the block diagram of figure 17. Updated HTML 1701 is 
posted via HTTP to the Web server 1702. The XPost interpreter 1703 acts upon 
XPost commands which may be stored in a hash table, dictionary or other data 
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structure 1704. The XPost interpreter 1703 controls updating of an XML instance 
1712 in a database 1711, which manages persistent storage. 
[0062] Figure 1 8 is a simplified flow chart for a method of updating a self- 
describing, structured document. The character string 1801 is received. The 
5 character string may be encoded according to any of a variety of standards, such as 
UTF-8. The character string includes an update operator or other indication of the 
desired operation, a path specification identifying a node or location within a self- 
describing, structured document, at which the update operator is to be applied, and 
one or more update values. One update operator may apply to a plurality of path 

10 specifications and update values. Alternatively, the update operator may be received 
as part of the URL that invokes processing or it may be implied by the maimer in 
which the update component is invoked. Update operators may include deleting an 
element, adding an element before an identified node as a sibling of the node, adding 
an element after the identified node is a sibling of the node, adding the element as a 

15 child of the identified node, or a combination of delete and add to accomplish a move 
or a replace. Other update operators can be supported. The past specification may be 
compliant with XPath or a subset of XPath. It is preferred to fully specify the path in 
absolute, instead of relative terms. Reference to identifying a node in the self- 
describing, structured document is not meant to imply that the document needs to be 

20 manipulated using the document object model or any other tree structured tool. The 
document can readily be manipulated with S AX-compliant tools or other event-driven 
tools. The character string is parsed 1802. A self-describing, structured document is 
accessed 1803. The document has a document type, which may be received or may 
be obtained from the document itself. The document may be accessed from disk 1811 

25 or may already be resident in memory when the character string is received. XML 
documents are among those that can be considered self-describing, structured 
documents. A schema corresponding to the document type of the document is 
accessed 1804. The schema may be accessed from a database 1812, disk or memory. 
The schema is used for validating 1804 application of the update operator and update 

30 values at the node identified in the past specification. The schema may be SOX- 
compliant, XML schema-compliant, or RELAX-compliant. Other schemas may 
apply to XML or non-XML documents. Following successful validation, the 
document is updated 1805 with update values at the node specified in the past 
specification. In some embodiments, the character string will include a document ID 



Page 39 of 47 



JGR 1008-1 



or a binary document ID will be sent in addition to a character string. In other 
implementations, the document ID will be implied by prior state information, in 
which case the document may already be in memory. All or part of the document 
may be accessed via a data-object-model data structure in memory. Any of the 
5 embodiments may be used with the past specification that is compliant with any 

version of an XPath standard. Similarly, any of the embodiments may be used with a 
schema that is compliant with any version of a Sox standard. In some embodiments, 
an element set will be constructed, such as a set of fields for a line item in a purchase 
order. A set of elements associated with a single location or node may be assigned a 

10 shorthand or alias and accessed or specified using the shorthand or alias. When an 
alias is used for a set of elements, more than one update value may be associated with 
a single pass specification. In addition to validation against the schema, this process 
may further involve validation against a business processing rule set. The business 
processing rules may be selected according to the document type, trading partner, or 

15 other criteria. The business processing rules may be implemented by a set of 
Schematron declarations or may be implemented in procedural logic. 
[0063] Figure 19 illustrates a protocol for updating a self-describing, structured 
document corresponding to one of a plurality of document schemas. The entities 
represented in this diagram are a requestor 1901, a respondent 1902 and a source of 

20 declarative transformations 1903. The protocol begins with receiving of request 1911 
identifying a starting document and specifying a document type to be generated from 
the starting document. The identification of the starting document and the 
specification of the document type may be received in two separate messages, so that 
the starting document is known from prior state information when the type of 

25 document is specified. The respondent, which may be a servlet running on a server, 
accesses one or more declarative transformations 1912, 1913 corresponding to the 
starting document and the specified document type. A rule selector may determine 
which declarative transformations are accessed. The system applies the declarative 
transformations to the starting document 1914, producing a plurality of path 

30 specifications for fields corresponding to the specified document type, starting values 
based on the starting document for at least some of the fields in some applications, 
fields to be completed by the user. The application of declarative transformations 
may produce a draft resulting document, a form, or both. In one embodiment, the 
system sends a form responsive to the request 1915 to the user, receives an updated 
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form 1916, validates the update information 1917 and generates a final resulting 
document 1919. Validating the update information may involve one or more types of 
validation, such as validation against the schema and validation against business 
processing rules. 

5 [0064] Figure 20 is a flowchart overview of validation. A document 2001 is 
received 2002. Optionally, a set of declarative rules 201 1 for validation is accessed 
2003. The declarative rules may include schema level validation based on a Sox 
schema and business logic level validation using Schematron. If validation fails on 
the schema level, field validation errors may be displayed without proceeding to 

10 Schematron validation. Validation errors may be displayed adjacent to the node at 
which the error was detected. If validation fails on the Schematron level, error 
messages may be displayed at the top of the user interface or wherever appropriate, 
using the XSLT document () function. The defaultxsl sample code set forth above 
includes logic for processing both Schematron and field validation errors. 

15 [0065] One or more errors in the primary document are detected 2004. A 

secondary self-describing, structured document 2012 including the detected errors is 
generated. For the detected errors, an error identifier and a path specification 
identifying a node within the primary document corresponding to one or more of the 
detected errors are generated. The primary 2001 and secondary 2012 documents are 

20 merged 2005 for display 2006. In one embodiment, the secondary document is an 
XML document. An enhanced version of the XSLT document () function is used to 
allow retrieval of the secondary document containing error text. The XMLPres 
component, which implements the XSLT functionality, is an enhanced version of 
Apache Foundation's Xalan. This component takes into account various concepts 

25 such as name spaces in Sox documents and polymorphism. Extension of the 

document () function enables the loading of an external document to be specified by 
the invoker. 

[0066] Figure 21 is a flowchart overview of a method of searching a plurality of 
self-describing structure documents, the documents including document fields. A 
30 server 2101 provides a user Interface 2102. The user interface includes, in one or 
more screens, the document type selection filter and one or more document fields 
selection filters. These document field selection filters are context sensitive to the 
selected type of document, if a document type is selected. One or more value 
specification fields are supplied, to be filled in for the field selection filters. These 
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value specification fields are context sensitive, so that field format errors, such as text 
characters in a numeric field, can be detected directly at the user interface, without 
return to the server. In addition, has non displaying fields, one or more path 
specifications corresponding to the document fields and the value specification fields 
5 are provided. The path specifications identifying nodes to be tested against the 

completed value specifications for a search. The server next receives data specifying 
a search 2104. This data typically comes from a user responding to the user interface. 
It includes the selected document type, completed value specifications and path 
specifications for the selected fields. Alternatively, aliases may be given for selected 

10 fields, which are expanded into path specifications by reference to a data structure 
2103. A search is conducted through a subset of self-describing, structured 
documents 2105, based on the completed value specifications and the corresponding 
path specifications. The subset includes documents of the selected document type. 
From the perspective of the user, the user interface displays a document type selection 

15 filter, one or more document field selection filters, which are context sensitive to a 
selected document type and one or more value specification fields, which are context 
sensitive to the document fields. Not displayed to the user, except perhaps a 
debugging mode, are path specifications corresponding to the document fields and the 
value specification fields. The path specifications identify nodes to be tested against 

20 completed value specifications when a search is conducted. The user selects a 

document type and one or more document fields appropriate to the document type. 
Value specifications are completed by the user. The user's selections are transmitted 
to a server which may then conduct a search. Recast as a device, the computer user 
interface includes a document type selection filter, one or more document field 

25 selection filters coupled by context to a selected document type, one or more value 
specification fields, coupled by context to selected document fields, and, has non 
displaying fields, one or more path specifications corresponding to the document 
fields and to the value specification fields. 

[0067] A context-based search facility is user configurable. Database 
30 configuration interfaces may be used for specifying those fields to be indexed. The 
user interface can be configured to provide user-friendly names to be displayed 
corresponding to XPath or field element name representations. Configuring the user 
interface permits fields that have different names in different document types to begin 
a common, user-friendly name at the user interface. Figure 22 identifies components 



Page 42 of 47 



JGR 1008-1 



of context-based searching. Upon receiving a new document 221 1, the generic 
document handling service 2212 will scan its configurations 2201 to determine if 
2213 the document has been configured for content-based searching. If the document 
type is configured to be searched, the system identifies fields to be indexed. In one 
5 embodiment, it uses the XPath specification of the incoming document fields to locate 
the indexable fields. After indexing, a process is invoked to persist the data 2221. 
Persistent indexed data is stored 2222. Further processing proceeds. Database 
configuration is supported by various tables. 

[0068] Figure 23 depicts a document type list used for database search 
10 configuration. A list, table or other data structure may be used to capture all 

document types recognized by the generic document handling system, or at least by 
the indexing system. The type ID column 2301 contains an integer value for an 
automatically generated field ID. This unique field ID is used as a shorthand for the 
document type. The type column 2302 is the character string identifying the 
15 document type. For instance, "request for quotation" is a document type. The name 
space column 2303 identifies the name space to which this document type belongs. 
The name space may be a uniform resource name that fully qualifies a location at 
which a schema for the document can be found. Column 2304 is an extra column 
reserved for future use. The application-created column 2305 is an integer used to 
20 flag fields in which data is entered manually. This field should be left null if data is 
entered manually. 

[0069] Figure 24 depicts a field definition table that is populated with path 
specifications of elements that will be searched. The field definition column 2401 is 
an automatically generated integer value, that is used as a shorthand for the field. The 

25 MPDD column 2402 is a unique identifier for a particular trading partner for whom the 
past specification that follows is valid. The type ID column 2403 is an integer value 
mapped to the document's type ID 2301. Many fields can be mapped to a single 
document type. The name field 2404 is a path specification. In some embodiments, it 
is an XPath for an XML document. 

30 [0070] XPath provides a unique way to identify a field inside a XML document, 
but it may not be meaningful to an end user. As illustrated in Figure 25, an alias to 
the XPath may be used as an alternative to embedding the full XPath string with each 
field used in the interface. The alias may be displayed in the user interface as a field 
name. The generic document handling system will associate the alias with the full 
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XPath string when user submits a request. The segment 2501 is an example of XPath 
and alias, segment 2502 is another example of multiple occurrence XPath and alias, 
segment 2503 is another example of different name space XPath and alias. 
[0071] Figure 26 is a table of searchable data extracted for indexing. The 
5 searchable field column 2601 identifies the field in which the data occurs. The 
document sequence field 2602 corresponds to the document in which the field was 
found. The field definition column 2603 corresponds to the field definition IDs in 
figure 24. The value column 2604 contains a searchable value. This value may be a 
single token or it may be the full contents of the field. A single token may, in some 

10 embodiments, include embedded blanks or other non-text characters. 

[0072] While the preceding examples are cast in primarily in terms of a method, 
devices and systems employing this method are easily understood. An electronically 
readable medium, such as a DVD, CD, memory module, magnetic disk or magnetic 
tape containing a program capable of practicing aspects the claimed method is one 

15 such device. A computer system comprising one or more servers and/or workstations 
having memory loaded with a program practicing the claimed method is another such 
device. 

[0073] While the present invention is disclosed by reference to the preferred 
embodiments and examples detailed above, it is understood that these examples are 
20 intended in an illustrative rather than in a limiting sense. It is contemplated that 
modifications and combinations will readily occur to those skilled in the art, which 
modifications and combinations will be within the spirit of the invention and the 
scope of the following claims. 
[0074] We claim as follows: 

25 
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CLAIMS 



1 LA method for error processing and reporting during validation of a business 

2 document in a client-server environment, the method including: 

3 accessing a first self-describing, structured document having a document type; 

4 validating the first document against a schema corresponding to the document 

5 type; 

6 generating a second self-describing, structured document including, for any 

7 detected errors, 

» 

8 at least one error identifier; and 

9 a path specification identifying a node within the primary document 

10 corresponding to the detected error; 

1 1 applying a declarative transformation to the first and second documents, 

12 producing a user interface character string, including a plurality of 

13 path specifications for nodes in the first document; and 

14 values for nodes in the first document; and 

15 at least one error message corresponding to the at least one error identifier; and 

16 transmitting the user interface character string. 

1 2. The method of claim 1, wherein the schema is compliant with any version of 

2 a SOX standard. 

1 3 . The method of claim 2, further including validating the first document against 

2 a set of business processing rules and generating a third self-describing, structured 

3 document, wherein the declarative transformation is further applied to the third 

4 document. 
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1 4. The method of claim 1, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 5. The method of claim 3, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 6. The method of claim 1, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 7. The method of claim 3, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 8. The method of claim 5, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 9. The method of claim 1, wherein the user interface character string is 

2 compliant with an XML standard. 

1 10. The method of claim 3, wherein the user interface character string is 

2 compliant with an XML standard. 

1 11. The method of claim 5, wherein the user interface character string is 

2 compliant with an XML standard. 

3 12. A method for error processing and reporting during validation of a business 

2 document in a client-server environment, the method including: 

3 accessing a first self-describing, structured document having a document type; 

4 validating the first document against a set of business processing rules applicable 

5 to the document type and an intended recipient of the first document; 

6 generating a second self-describing, structured document including, for any 

7 detected errors, 

8 at least one error identifier; and 

9 a path specification identifying a node within the primary document 
10 corresponding to the detected error; 
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1 1 applying a declarative transformation to the first and second documents, 

12 producing a user interface character string, including a plurality of 

13 path specifications for nodes in the first document; and 

14 values for nodes in the first document; and 

15 at least one error message corresponding to the at least one error identifier; and 

16 transmitting the user interface character string. 

1 13. The method of claim 12, wherein the business processing rules are 

2 Schematron-compliant. 

1 14. The method of claim 12, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 15. The method of claim 13, wherein the declarative transformation is compliant 

2 with an XSLT standard. 

1 16. The method of claim 12, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 17. The method of claim 13, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 18. The method of claim 15, wherein the user interface character string is 

2 compliant with an HTML standard. 

1 19. The method of claim 12, wherein the user interface character string is 

2 compliant with an XML standard. 

1 20. The method of claim 13, wherein the user interface character string is 

2 compliant with an XML standard. 

1 21. The method of claim 15, wherein the user interface character string is 

2 compliant with an XML standard. 
J 
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ABSTRACT 

The present invention includes a method and device for generic searching 
across document types. A further aspect of the present invention is indexing and 
searching XML documents using an HTML interface generated by a declarative 
transformation. Additional aspects of the present invention are described in the 
claims, specification and drawings. 
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